Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security The Internet

Mitigating Password Re-Use From the Other End 211

Posted by Soulskill from the 12345-goaway-letmein dept.
An anonymous reader writes "Jen Andre, software engineer and co-founder of Threat Stack, writes about the problem of password breaches in the wake of the LivingSocial hack. She notes that the problem here is longstanding — it's easy for LivingSocial to force password resets, but impossible to get users to create different passwords for each site they visit. We've tried education, and it's failed. Andre suggests a different approach: building out better auditing infrastructure. 'We, as an industry, need a standard for auditing that allows us to reliably track and record authentication events. Since authentication events are relatively similar across any application, I think this could be accomplished easily with a simple JSON-based common protocol and webhooks. ... [It] could even be a hosted service that learns based on my login behaviors and only alerts me when it thinks a login entry is suspicious— kind of how Gmail will alert if I am logging in from a strange location. Because these audit entries are stored on a third-party box, if a certain web application is compromised, it won't have access to alter its audit log history since it lives somewhere else.'"
This discussion has been archived. No new comments can be posted.

Mitigating Password Re-Use From the Other End More

Mitigating Password Re-Use From the Other End

Comments Filter:

  • This seems like a good way to enforce strong password policies. if they are strong enough; they should help prevent password re-use. The only problem with this is the problem of people writing these down. We need a better online authentication system for 2013.

    • How does using a strong password prevent password re-use?

    • Re:Forcing strong passwords in the first place. (Score:4, Insightful)

      by Dunbal ( 464142 ) * on Sunday April 28, 2013 @05:36AM (#43572783)
      How about instead coding a site properly so it won't get hacked in the first place? Put the effort and resources there.

      • Re:Forcing strong passwords in the first place. (Score:5, Interesting)

        by T-Bone-T ( 1048702 ) on Sunday April 28, 2013 @07:31AM (#43573185)

        +5? The only way to keep a website from getting hacked is by not connecting it to the internet in the first place. Effort should certainly be put into making it difficult to hack but also making it difficult to gain anything valuable when you are hacked.

        • Re: (Score:2)

          by funkboy ( 71672 )

          Effort should certainly be put into making it difficult to hack but also making it difficult to gain anything valuable when you are hacked.

          Exactly. That's one of Schneier's central arguments [wikipedia.org] as to why sites getting "hacked" is so prevalent today. Once some initial security perimeter (e.g. a firewall) is breached, system design & security is sloppy enough that it's a free-for-all for the intruders. If systems were designed as a fortress built to secure data this would be a lot less of an issue, as unsuccessful crackers are broke crackers that need to start looking for income elsewhere.

        • Re: (Score:2)

          by gutnor ( 872759 )

          Right, but the alternative are either user education or local solution on the user machine (keychain tool). The first one will not happen, that much should be clear by now. The second one is a matter of opinion - you need to believe the users can be collectively better at fighting malware creators than website developers at fighting dedicated cracker. It seems that recently both the botnets and general website cracking have been going well, so the jury is still out.

          Egoistically, I would rather have the w

        • Re: (Score:2)

          by Hentes ( 2461350 )

          Keeping the site secure is the company's responsibility. Choosing passwords is the users' responsibility. Yes, they should work on their side of the problem, and let the users decide whether they want to take the risk of a weak password.

      • Re: (Score:2)

        by smash ( 1351 )

        You're just pushing TRUST out to the remote site. Are you really sure that EVERY single website you use is likely to adhere to any sort of sane security standards, and have competent security-aware web developers?

        Random usernames. Random passwords. This whole "your email address is your username" thing is retarded.

    • easy, just take the users attempted password and user name and try and log in to any of 100 other sites with it, if you can then reject it.

      • That requires the site that your trying to log into to store the passwords, which is a really Bad_Idea(tm), the site should only store a crytographic hash of the password and a salt value; please don't use a simple md5sum hash. Now if the site gets hacked and the database is stolen, the 'ner-do-wells don't have the passwords. Storing the md5 hashes doesn't work, there are plenty of lists of passwords and their md5 hashes out there.

    • My passwords all come in the following variations

      yyyyyy
      xxxxxxxxxx
      Xxxxxxxxxx
      Xxxxxxxxxx1
      Xxxxxxxxxx_1

      tell me again how strong password policies prevent re-use.

    • Password policies are voodoo. They may make it more difficult for stupid users from using weak passwords, but they do not reliably prevent it, and they actively inhibit the use of strong passwords [xkcd.com].

      • Re: (Score:3)

        by sosume ( 680416 )

        Exactly. I hate it when some site first forces me to register, and then even has the balls to require a complicated password, assuring in the process that I won't become a returning visitor.
        My usual password strategy is that I use a one very simple password for all systems that cannot harm me in any way. Such as news sites, free games, etc. Who cares if anyone can post under my name. For paid-for stuff and sites I leave personal details etc, I use a strong password, with alternating user names. Then when I

        • assuring in the process that I won't become a returning visitor

          And they aren't bothered by that - their policies are designed for the vast majority, not the one-in-a-million asshat.

      • Sigh, somebody else trots out that stupid XKCD cartoon without understanding it.

        The example that he used substituting for troubadour with a 2 character chaser is not something that has ever been recommended password policy anywhere I've seen recommendations made. It was specifically warned that you not take a dictionary word and transliterate it into leet speak because it wasn't a strong password.

        Bottom line is that the suggested option is easier to reconstruct than a random password and that once you get m

      • THIS. Why not let me use the kind of strong password or passphrase that works for me? A password policy that has random restrictions (at least one number, at least one uppercase letter, no more than three lowercase letters in a row, etc.) just encourages the shortest weakest password that barely satisfies the constraints.... and it gives hackers information to figure out what passwords probably look like.

        Just give people a realistic password meter, set some minimum level of complexity, and let them deci

    • I am so sick of websites that try to force "strong" password creation by creating their own rules. I have several strong passwords that I use that aren't considered "strong" by many websites (it is a nonsensical sentence with misspelled words). When you force me to add capitals and numbers and likely symbols, it's just going to cause me to change "thequickbrownfoxjumpsoverthelazydog" to "Thequickbrownfoxjumpsoverthelazydog1$" and then when attempting to log into the site I'll have to enter several variation

      • Apologies if this is a silly question, but doesn't requiring specific characters reduce the set of possible passwords, making it easier to crack?

        If I know there has to be a numeric (and max length is 8) I don't have to try ABCDEFG[A-Z], for example.

        • Re: (Score:2)

          by tqk ( 413719 )

          ... doesn't requiring specific characters reduce the set of possible passwords, making it easier to crack? If I know there has to be a numeric (and max length is 8) I don't have to try ABCDEFG[A-Z], for example.

          ABCDEFG[0-9]
          [0-9]BCDEFG
          A[0-9]CDEFG
          AB[0-9]DEFG
          ...
          [0-9]bcdefg
          ...

          Add the potential of "`~!@#$%^&*()-_=+[{]}\|,;:'"/?" in the square brackets and numerics instead, now you're talking secure. Why none of the graybeards back in the dark ages didn't come up with an RFC that codified Best Practice for this stuff, I don't know. Once you find yourself logging into Windows, OSF/1 (True64), AIX, HP-UX, Solaris, Linux, *BSD, and Mac, *times 2* (user + root/admin), you begin to see how abysmally this problem has

    • Well, we could subsidize all the Dunder Mifflins out there, and then outlaw paper. . .
      But then people could carve the passwords into the furniture. . .
      Outlaw furniture?
      But Congress never holds itself accountable, so there'd be a bunch of people standing/laying on the Mall, calling Congress a pile of dicks.
      Something should be done to make people more controllable.

    • The only problem with this is the problem of people writing these down.

      Isn't there anything better than passwords, that would be unique, anonymous and disposable (destroyable)?

  • 3rd party box (Score:3)

    by Frankie70 ( 803801 ) on Sunday April 28, 2013 @05:24AM (#43572735)

    Because these audit entries are stored on a third-party box, if a certain web application is compromised, it won't have access to alter its audit log history since it lives somewhere else.'

    Since the audit entries are being created by the box running the application, it obviously has write access to the 3rd party box. So whoever has access to the application box has access to write (and hence alter) the 3rd party box.

    • The sites can only send new log entries to the third party server, not modify existing entries. Any bogus records would have the effect of locking down the accounts that the hacker is sending bogs data for. Adult sites have been doing this for many years using systems like Strongbox, and it works.

      To clarify something other people brought up, the remote audit system doesn't store passwords. It stores information about log-in events - who logged in from where, using what type of hardware, which browser,

  • Passwords are unfixable (Score:2, Interesting)

    by Anonymous Coward

    You can tack on more mitigation, but in the end it's the concept that's flawed, not the implementation.

  • how about store your passwords properly? (Score:5, Insightful)

    by Trepidity ( 597 ) <delirium-slashdot@@@hackish...org> on Sunday April 28, 2013 @05:32AM (#43572759)

    it's easy for LivingSocial to force password resets, but impossible to get users to create different passwords for each site they visit

    It also ought to be easy for LivingSocial to store passwords hashed with a secure hash designed for passwords, like scrypt [wikipedia.org] (or the related bcrypt). That way even if the password db is compromised, the plaintext passwords aren't, and the attacker cannot use the result to get into other services, even if users shared passwords across services.

    It's easy to blame users, but there has been no excuse for storing plaintext passwords for years now. Password reuse is a much smaller problem if websites are designed properly. So rather than "as an industry" attempting to change user behavior, how about "as an industry" implement your damn sites properly, and audit that.

    • Replying to self: It looks like LivingSocial actually has switched to bcrypt now. But not early enough!

    • It also ought to be easy for LivingSocial to store passwords hashed with a secure hash designed for passwords, like scrypt [wikipedia.org] (or the related bcrypt).

      It's easy to blame users, but there has been no excuse for storing plaintext passwords for years now.

      Yes! I can't believe there are websites out there that still don't hash passwords.

      A few months ago I signed up to the website of a large health insurance provider, and they sent me an email confirmation of my account creation that included my website password in plaintext. Unbelievable.

      Who writes this stuff? And who hires these people?

      • Re: (Score:2)

        by dingen ( 958134 )

        Putting your password in an e-mail during the registration process doesn't mean they store it in plain text in their database. If they can come up with your password at a later point (like when requesting a "lost password"), THEN you know they are storing their passwords in plain text.

        • Putting your password in an e-mail during the registration process doesn't mean they store it in plain text in their database.

          But it does mean that they send the password in clear text rather than hashing it on the client.

          Clear text passwords should never be sent over the Internet, even over secure channels.

  • You just made it easier for cracking. (Score:4, Informative)

    by mjuarez ( 12463 ) on Sunday April 28, 2013 @05:35AM (#43572779)

    So, what happens when that central framework/infrastructure is cracked? Now, all cracking attempts will redirect to that single point, and when (not if) it's breached, they'll now have access to ALL websites that are signed up to use that. How is that better?

    • Re: (Score:3)

      by gl4ss ( 559668 )

      So, what happens when that central framework/infrastructure is cracked? Now, all cracking attempts will redirect to that single point, and when (not if) it's breached, they'll now have access to ALL websites that are signed up to use that. How is that better?

      that you have to just use one complex password at one place and have to change it just at one place.

      however the author is a dumb fuck who apparently hasn't heard of any of the SSO services...

    • The audit system doesn't store passwords. It stores information about log-in events - who logged in from where, using what type of hardware, which browser, which version, etc. It then audits that information. Suppose for the life of your account you've always logged in from Kansas, US, on either a Mac using Safari or an iPad. Today, someone claiming to be you is trying to log in using a Windows XP machine in Russia, and also someone claims to be you logging in from a web server in China. The system would fl

  • Or, alternatively... (Score:4, Insightful)

    by neokushan ( 932374 ) on Sunday April 28, 2013 @05:36AM (#43572785)

    If you're security conscious enough to put this fancy bit of JSON on your site, then most likely you're smart enough to not store your user's passwords in plaintext. In fact, I'd like to think you're clever enough to salt the hash of the passwords that you're storing as well.

    Why am I pointing this out? Because password re-use is an issue when a password gets compromised. Passwords get compromised when they're not encrypted or hashed. So to "fix" the problem like this is all well and dandy, but it only works if every site does it and if every site hashed the bloody passwords in the first place, they wouldn't get compromised as often.

  • one key to rule... (Score:2, Interesting)

    by Anonymous Coward

    Or we could just use GPG authentication, where a user simply uploads his public key to the site. User's happy, because s/he can use the same passphrase everywhere and the site is also secure because even a hack won't divulge any passwords. Separate (key-less) password could still be optional.

  • Too many damn passwords (Score:4, Interesting)

    by seeker_1us ( 1203072 ) on Sunday April 28, 2013 @05:51AM (#43572837)

    If you have too many different username/passwords you will not be able to keep them straight. This is what OpenID was supposed to solve. One can flip the argument around very easily: if there were fewer sites maintaining their own password databases, then there would be fewer breaches.

    And that does NOT mean using OpenID for everything including financial accounts.

  • Still a issue that Devs won't acknowledge (Score:5, Interesting)

    by Quick Reply ( 688867 ) on Sunday April 28, 2013 @06:01AM (#43572859) Journal

    The thought process of a developer is that it is usually a user problem, and therefore it is the user that needs fixing, not the user.

    The cold reality is that using passwords at all is the problem.

    Passwords are an antiquated solution to a simple problem from the very start of multi-user computing. It is simple but exponentially ineffective as it scales.

    The human mind is not set up to remember multiple, complex passwords. There are very few humans who are gifted with this ability to remember literally hundreds of different passwords without writing it down, I would put someone who can in the realm of an academic genius who can remember entire textbooks or recite Pi for hours before they eventually have to take a break for physical reasons.

    Normal people write it down or keep it to a narrow set of passwords depending on which level of complexity the system will allow. Both bad security practice.

    And passwords that expire every 45 days with annoying complexity requirments? You're going to drive users nuts trying to think of new ones each time that eventually they will come up with the simplist password the system will allow and increment by 1 each time they have to change eg: Password1, Password2, Password3, etc.

    There are hacks out there, eg: KeePass and LastPass, but this is a workaround to the underlying problem. The websites that Force you to use Facebook are even worse (as they force you to handover all your personal details while you are at it, which just as easily can be used for identity fraud. Many Banks, Telcos etc. only authenticate with your DOB). OpenID is better but the implementation makes it common to sign in from the website your are trying to access, making it susceptible to being spoofed.

    Realistically, we need to kill the password. Two factor authentication all the way. It needs ONE trust relationship between the user and the authenticator. This could be a user ID and a token. The authenticator can have then multiple trust relationships with participating websites.

    The authenticator should only provide two data points: (1) The user ID of that website (different ID to other websites so that the user can be tracked with the same ID across websites) and (2) That the user has authenticated themselves. Thats it. Most websites don't need to know your name, DOB, Vanity username, email address or anything else about you. If they need this, ask - but only if actually required - and give the user a clear option to decline or provide only partial data.

    The only thing that most websites or other computer systems need is a way to tell which user profile to load up, and that the user requesting it is really the same user. A password does not prove that,

    • I disagree. Zero factor authentication works beautifully for everything online.

      For the physical world, there's cold hard cash -- The Great Authenticator.

      • Then how come you are posting as VertexCortex and not Anonymous coward, still needs to be a mechanism to make sure you are VertexCortex. Ideally you should be able go hit "Login" on your browser, and your browser automatically logs you in for you while using two factor in the background (once you have already two-factored with your browser when you sat down) so Slashdot knows 1. You are VertexCortex (to load your preferences and posting abilities as your name) and 2. You have proven yourself (It doesn't ne

  • nightmare (Score:3)

    by stenvar ( 2789879 ) on Sunday April 28, 2013 @06:37AM (#43572995)

    'We, as an industry, need a standard for auditing that allows us to reliably track and record authentication events.

    That sounds like a security and privacy nightmare.

    but impossible to get users to create different passwords for each site they visit. We've tried education, and it's failed.

    Perhaps users just don't give a f*ck whether their account on some third rate e-commerce marketing site gets compromised?

    If I were to create an account on LivingSocial, it would get my "disposable" password, the password for accounts I just don't care about at all. Only gradually do accounts and services migrate into the category where I bother remembering a specific and hard password for them.

    • Re:nightmare (Score:4, Interesting)

      by vtcodger ( 957785 ) on Sunday April 28, 2013 @07:51AM (#43573269)

      If I were to create an account on LivingSocial, it would get my "disposable" password, the password for accounts I just don't care about at all. Only gradually do accounts and services migrate into the category where I bother remembering a specific and hard password for them.

      That's rational.

      Frankly, most password security "thinking" seems to me demented. There is no way I or most anyone else could possibly keep track of hundreds of different strong passwords with arbitrary characters, random case, etc without writing them down. And maybe not then.

      And there is no practical way that I could secure that password list.

      Neither is it likely that information providers can secure password information -- strong, weak or non-existent -- on their end. That's why massive password breaches are a daily event.

      Bluntly, the industry's attempts at security can't and don't provide much security and are more a massive usability problem than anything else. How is "user education" supposed to overcome faulty engineering?

      Look folks, the method you want to use to secure stuff simply doesn't work very well. Never has. Never will. Forget about "educating" users, and start thinking seriously about how to secure stuff, and whether most of what you are trying to "secure" actually needs securing. Maybe in decade or three you'll come up with something that works.

      In the meantime. Get real.

  • Don't brush your problem off on the user (Score:5, Insightful)

    by Opportunist ( 166417 ) on Sunday April 28, 2013 @07:04AM (#43573085)

    I see it very often in audits, company security is facing the same problem: How to secure the network? The easy way out: The user has to do it. He has to come up with a password that fulfills the most inane requirements AND must remember it AND must not note it down.

    That's the easy way out. All the burden is shifted to the user.

    I consider it extremely patronizing if they then go, after a breach, that they tried to "educate" the user but failed. Well, DUH. Guess what. It's not the user's job to keep your database secure. It is his job to make sure his credentials don't get handed over to a third party, yes. But it is YOUR job to make it possible to him. And it is NOT possible for the average human being to remember passwords in the style of k$aUZ_nR2o.

    Don't try to shift a problem that YOU have to solve onto your users!

    • And it is NOT possible for the average human being to remember passwords in the style of k$aUZ_nR2o.

      Obligatory XKCD: http://xkcd.com/936/ [xkcd.com]

    • The user has n interest to make sure that if one site he/she logs into gets hacked, the damage does not spill over into other websites. The websites have a completely different cost/benefit scenario. Security is seen s cost. Do the minimum required to identify the users, remember their settings/preferences, give users some vague sense of security. That is all the web sites are going to do. Unless the user demands better security they wont provide it. You think there will be enough users demanding more secur

  • Don't make users log in with their email address. Give them a randomly generated username and password combination.

    This whole practice of forcing you to use an EASILY identifiable piece of information (your email) as one of the autentication factors is just retarded.

    • great, so now we have to remember both a username AND password? That'll make this whole thing even worse! Even worse, if my login is taken on one website then every website has a different log in (and password likely). So now I'm remembering 2xN pieces of information instead of just N.

      • Re: (Score:2)

        by smash ( 1351 )
        Yes. Put it in a keychain, paper, or whatever. You can't "remember" properly secure randomly generated passwords for each website anyhow.

  • Forget passwords, worry about "Secret Questions" (Score:5, Insightful)

    by Ottibus ( 753944 ) on Sunday April 28, 2013 @07:33AM (#43573201)

    All this concern over passwords is ignoring the much greater problem of so-called "Secret Questions". This is a mechanisms that positively encourages people to use the same security information on every site they visit and to give answers that can easily be guessed by other people.

    How many sites hash the answers to these questions so that they can't be re-used by a hacked who breaches the site (or a corrupt employee)?

    How many users take care to give a different wrong answer to these "Secret Questions" every time?

    The complexity and variablility of the password reset process can make this mechanism less susceptible to automated attack, but if you want to attack a specific account of a known person this is a much better route that trying to crack the password.

  • 1. It is in the best interests of the users to use different passwords for different sites. Simplest thing to do is to use a 8 char string as the base password and append, prepend or insert a three char string based on the web site name into it. Each site has its own password, but it would not be easy to use a compromised password at other sites. It is in the best interests of the users to do it. For sites security is just cost, they do the minimum. Rotate the base password once a year or so.

    2. We should ask the more important accounts like brokerage, mutual fund, bank accounts to use a two factor authentication system. But I don't want to juggle too many RSA key fobs. I like google sending a six digit code to the designated cell phone. Google also lets you set up 10 one time pad numbers ahead of time to handle the case when the cell phone cant get texts. As a first step if they would just send me text or an email for each login event and each transaction that would reduce fraud.

    3. What really bugs me is, in this day and age of social network where people are posting details of their breakfast lunch and dinner for the whole world to see, even banks use "maiden name of mother" "name of your pet" or "where you went for honeymoon" to reset passwords. That is insane. So I used to give non intuitive answers like "nissan sentra" as the mothers maiden name. But it is so difficult to remember what stupid answer I gave to which site. That is my biggest beef with these security questions.

    4. No I did not switch my username and password edit boxes when I signed up for slashdot. Friends recognize the dorm addresses, rest of alumna recognize the dorm names.

    • What you suggest is already available via add-in password hashers on the users end. Passwords are automatically generated and salted with the URL. You can "bump" a password to change the salt. The main problems I've come across are:

      1) The algorithm differs by browser, even those that say they are compatible.

      2) Some password entry points don't have a hasher function built in, requiring me to either write down the password or switch to the browser to get it.

      All of my password hashing efforts are moot if th

      • My problem with such hasher is that, I did not write it. I am not trusting all my passwords to some binary blob. How do I know the add-on/extension/app is not phoning home all my passwords to some chinese hackers? That is why I use my own brain to do the hashing and salting. I am not so paranoid about passwords to minor accounts like slashot or app dev. Even medium level accounts like amazon or gmail is ok. But each my bank/brokerage account gets a personalized password that is not written down, not generat

    • Simplest thing to do is to use a 8 char string as the base password and append, prepend or insert a three char string based on the web site name into it.

      I used to do this, but the problem is that it only protects against automated attempts to abuse a compromised password. If I happen to have bought something at EvilWebshopHosterX and made an account with BasePasswordEWHX, it's easy for anyone that gets their hands on the password to figure out all my other passwords based on the scheme.

      Rotate the base password once a year or so.

      This is a terrible hassle and generally leads to having to try multiple base passwords before giving up and using the password reset mechanism because at that particular webs

  • The old spam solution form at http://craphound.com/spamsolutions.txt [craphound.com] covers most of the solutions being proposed here.

    http://craphound.com/spamsolutions.txt [craphound.com]

    Common spam problems such as "Ease of searching tiny alphanumeric address space" and "Jurisdictional problems" translate easily to the common password problems of "sending passwords via email is inherently insecure" and "requiring unique passwords for each trivial new website creates enormous keychains that are not safely por

  • Firefox already has password tools - it can optionally store the password from different sites. It should be simple to extend this to warn the user if any two passwords are the same.

    Firefox uses *local* storage for this, on the user's computer, so it will be more secure than any remotely-hosted solution.

  • I have a low-security password that I use for Slashdot and most web sites. I have a very high-security password that I use with my bank (it depends on a number that has not been written down anywhere for fifty years). The idea of needing a unique password for every web site is rediculous. What do I care if yahoo.com is hacked and somebody logs in to Slashdot as me? Impersonation is not a serious problem.

    (Result: I can not guarantee that I wrote this message. So what.)

  • Wrong approach in use. Secrets should be local (Score:5, Interesting)

    by Morgaine ( 4316 ) on Sunday April 28, 2013 @09:39AM (#43573657)

    The sites that are calling for better password choice need to step back a bit and consider whether their design concept of storing user passwords centrally is a good one. It's not, so they should get rid of it instead of applying band aids to a bad scheme.

    It doesn't matter what encryption scheme is used, if authentication secrets are stored centrally on a website then they are at risk. Good sites make it hard to crack, and poor sites make it easy, but they are all at risk, from internal employee corruption if nothing else. Those secrets will leak because when stored at a single point then they are all accessible to the attacker at a single point. Leakage is just a matter of time.

    A vastly more secure approach that's been well known for decades is for the user to store their secret locally as a private key, one half of a {private,public} key pair. The server only gets to know the public key (PK), and it's pointless for an attacker to crack that because the PK is public information that can be distributed freely through keyservers. (The PGP/GnuPG keyserver network has been doing this for decades.)

    When a user creates an account on some website, she provides the identifier of her chosen PK (she may have lots of them). When logging in to the account subsequently, the server looks up her PK identifier in the info for this account, fetches her PK from the keyservers, then it sends her a random string encrypted with her PK. She decrypts it with her private key (which is only held locally by the user, nowhere else) and sends the decrypted string back. The server accepts the login if the returned string matches the random string that it picked, which is not stored and varies on every login, and rejects the fraudulent login attempt if the match failed.

    That's strong distributed security, and it's resistant to MITM attacks and does not store any authentication secrets on the central service so those secrets cannot leak when the service is compromised.

    It's not rocket science. Why this old but secure scheme isn't used by websites is quite a mystery.

  • I don't know why more people don't use solutions like Lastpass. I have one very long and difficult to guess password (but easy for me to remember), and every site I visit has a unique psudo-random gibberish password. If a site does something really stupid like store passwords of their users in plaintext, a breach will only allow access to that site since that password is used nowhere else. This method is impervious to dictionary attacks, hash-table lookups, etc. It's a tiny bit of an inconvenience, but

  • Completely missing the point (Score:5, Interesting)

    by swillden ( 191260 ) <shawn-ds@willden.org> on Sunday April 28, 2013 @09:58AM (#43573719) Journal

    The problem isn't that users use the same password on every site. The problem is that users have to create login credentials for every site they use.

    That multiplication of logins is extremely inconvenient for users, and it's simply not practical for people to create good, unique credentials for every site and memorize them all. So people who care a lot about security are are willing to put in the effort (read: anal geeks) use encrypted password stores and such. Everyone else (read: 99+%) uses the same password or small set of passwords on all sites.

    What's really stupid is that we have already solved this problem, and in a much better way then Jen Andre proposes. The solution is single-sign-on. Delegate account management and authentication to a trusted third party (TTP). Even better, allow many organizations to act in this role. Best of all, allow users to choose which TTP they want to use, or even to act as their own.

    We've already built this. It's called OAUTH. Moreover, there are already a bunch of high-profile OAUTH implementors acting as TTPs -- and nearly all Internet users already have an account with at least one of them (e.g. Google, Facebook, Yahoo, Microsoft). For that matter, there are a number of sites already taking advantage of it to provide nearly zero-effort login (for example, stackoverflow is one that many slashdotters may use).

    The common security objection to this approach -- that centralizing your authentication in a single account creates a single point of failure for your security -- ignores the fact that your web security already has a single point of failure, even if you use unique, strong passwords for every site you visit. That SPOF is your e-mail account, because essentially all web sites use the ability to receive e-mail as the golden key that bypasses all of their other security mechanisms.

    But, with OAUTH you still have the ability to use different providers, and even to set up your own on a server you control if you like. You can choose the tradeoff between centralization and decentralization you like. No relying site will ever see any of your credentials. You can also pick a provider based on the level and type of authentication security they provide. Personally, I'm very happy with Google's two-factor authentication -- but OAUTH imposes no restrictions. Want certificate plus one-time-password plus fingerprint plus retina scan plus 100-word passepic? Fine. Find (or build) a provider that does that. Want nothing at all? You can have that, too.

    And whatever you choose, none of the relying sites will ever have any of your credentials. Which means creators of those sites can't screw up storing your credentials.

    The only thing that's required to make all of this work, for real, everywhere, is for sites to offer OAUTH authentication. It's easy, it's super convenient for users, it's as secure as the provider.

    Some sites might choose to limit the providers they'll accept, on the theory that users can't be trusted to choose a good one. That's annoying and obnoxious, but whatever. Some sites (like banks) might decide that they simply have to do their security themselves because they can't trust anyone else, and They Are A Bank. Okay, fine, though such sites should be a tiny minority (and, frankly, as someone who worked as a banking security consultant for over a decade, and now works for Google doing security, Google -- and, I would expect, the other major Internet properties -- do a far, far better job at online security than virtually any bank).

    The solution is to make OAUTH the default, expected login mechanism all over the web. It provides dead-simple, reasonably high security authorization for the masses and allows the paranoid to build/buy whatever they want.

  • The thing is ... (Score:4, Interesting)

    by MacTO ( 1161105 ) on Sunday April 28, 2013 @10:02AM (#43573735)

    I have numerous accounts for everything from forums to banking. Some are clearly important, while others are not important. The important accounts get the strong passwords, passwords that aren't reused (even in terms of a significant modification). The unimportant accounts have reused passwords, with the only real rule being that the password is different from accounts that may somehow be correlated (e.g. through their authentication mechanism or username).

    The problem with preventing reuse is (a) every service thinks that they are the most important thing since the creation of the universe and (b) strong, non-repeated passwords have their own inherent insecurities.

    By inherent insecurities I mean things like people recording their passwords. Written records and unencrypted electronic records can be read by anyone. These digital key managers secure all passwords with a single password, may they be locally hosted or remotely hosted. Records of any form run the risk of tying all accounts together rather than keeping them separate. Even those who memorize their passwords run the risk of entering the password for service A into service B.

    Of course the people who think about security usually think about the things that they can control, which is the combination of bits. They rarely seem to address the psychology of the people using their mechanisms (outside of complaining or making unrealistic demands). If they want to create secure systems they need to apply human psychology, and recognize that security is often being applied where it is unimportant.

  • Hmm. Now who [threatstack.com] might be offering just such services?

    I thought I checked "Ads Disabled".

  • So... they want to reinvent RADIUS [wikipedia.org]... again.
  • Welcome to Joe Schmoe's website. Please create your account.
    Username: halcyon1234@example.com
    Password:12345
    Checking...
    Server-side...
    IF EmailLoginChecker.TryLogInToMailSystem("example.com", "halcyon1234", "12345") THEN
    Error = "You're using the same password as your email address. We're mitigating that risk. Idiot."
    ELSE RegisterUser();
    END IF

Slashdot Top Deals

On the eighth day, God created FORTRAN.

Close