Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Open Source Security

Ask Slashdot: Definitive Password Management Best Practices Using OSS? 77

Posted by Soulskill from the plan-for-the-worst-hope-for-the-best dept.
jmcbain writes: I am an software engineer for a client-server user account system handling both Web and smartphone clients. I have been searching for definitive and crystal-clear best practices for managing user account and password data using open-source software, but I have only cobbled together a complete picture from dozens of websites. I currently have a system that sends passwords over SSL and performs bcrypt hashing for storage and authentication checking at the server side. Is that good enough? The recent Ashley Madison breach and the exposure of MD5-hashed passwords (as opposed to bcrypt) has me worried again. Can someone please suggest a definitive, cookbook-style Web resource or book on how to use open-source software to handle user passwords for multiple client-server scenarios? I would like answers to questions such as: Where do I perform hashing (smartphone/web client or server)? What hash algorithm should I use? How do I store the hashes? How can clients recover forgotten passwords? etc.
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Definitive Password Management Best Practices Using OSS? More

Ask Slashdot: Definitive Password Management Best Practices Using OSS?

Comments Filter:

  • Solved... (Score:5, Informative)

    by Anonymous Coward on Saturday September 12, 2015 @05:29AM (#50508737)

    Owasp authentication cheat sheet:

    https://www.owasp.org/index.php/Authentication_Cheat_Sheet

    • Re: (Score:1)

      by Anonymous Coward

      Mod parent up! That is a very useful resource.

      Note that it doesn't meet the complete criteria of the question, because they're looking for a unicorn:

      ... searching for definitive and crystal-clear best practices

      There are simply too many variables involved for someone to write down the simple step-by-step instructions they seem to be asking for.

      • See the link from the paper here: https://www.youtube.com/watch?... [youtube.com]

        Make them long - make them memorable forget the upper/number/Special nonsense.

      • There are simply too many variables involved for someone to write down the simple step-by-step instructions they seem to be asking for.

        There is one point that is pretty much cast in stone: there is no such thing as "secure password recovery".

        Maybe OP did not mean that literally, but if a password can be "recovered", it isn't secure. There is no way to have both.

        Passwords are replaced using a reset process, not recovered.

    • Re: (Score:1)

      by Anonymous Coward

      generate new passwords.
      HASH on servers.
      SHA seems pretty good these days. Y use a KNOWN WEAK and BROKEN HASH? Thats asking for trouble.
      Make sure you have enough good entropy. HAVEGED Audio entropy, etc.etc. Theres network entropy too.

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Saturday September 12, 2015 @05:32AM (#50508745)
    Comment removed based on user account deletion

    • Re:"How can clients recover forgotten passwords?" (Score:5, Informative)

      by w3woody ( 44457 ) on Saturday September 12, 2015 @06:35AM (#50508863) Homepage

      If you use a one way hash that has been properly salted (i.e., HASH(SALT + password) ), then you should never be able to retrieve forgotten passwords, ever. If you can retrieve a lost password for a user, then you've screwed it up, because if you can recover a lost password, someone who scraped your database can recover a lost password.

      The worst, by the way, are web sites which require you to pick a super-secure password (at least 12 characters long, must contain punctuation, both upper and lower case letters, a number character, an Egyptian hieroglyph, and must not match the last 15 passwords used in the past and must be changed ever 30 days)--then stores the password and password history as plain text in the user database. Those are the guys I'd love to murder in cold blood.

      Personally I've always liked using some element of a user record attribute as part of the SALT--such as having a UUID associated with each user record that becomes part of the salt for the hash (i.e., HASH(SALT + password + UUID) )--because this means if someone does scrape your database it's computationally a little more difficult to reverse engineer the passwords in the database because even a bunch of people use "123456" as their password, the hashes will be different for each of those users. Of course the UUID must never change or else you'll lock your users out.

      I'm also a fan of the POP3 protocol's APOP authentication mechanism, where sending credentials over the 'net requires two transactions: (1) obtaining a unique token for that session, then (2) hashing the password against that token to transmit to the back end. Of course this means you wind up hashing the plain text password *twice*: since you don't have the password on the back end (but its hash) you can only compare against HASH(TOKEN + hashed_password), and on the front end you wind up calculating HASH(TOKEN + HASH(SALT + password + UUID) ). But that requires a lot of work in the client.

      Simply sending HASH(SALT + password + UUID) rather than hashing the hash with an additional token means you're subject to a replay attack, where a third party could listen in on the conversation and simply replay the login packet you send to connect to the server.

      And while I know a lot of folks claim that all of this is mitigated by using SSH, it doesn't protect against man-in-the-middle attacks, including incidental man-in-the-middle attacks created by certain proxy gateways which use their own certs in order to decrypt HTTP traffic to sniff for viruses or enforce corporate guidelines for acceptable use.

      Ultimately security won't stop the most determined hackers; you're not stopping the NSA, for example. But you can stop the script kiddies and disgruntled employees by taking some precautions--such as never storing sensitive information in a database (like credit cards) unencrypted, and using one-way hashes to store passwords.

      Oh, and as a footnote: unless you have a Ph.D. in cryptography, don't write your own random functions or hash functions. Yes, I've seen it in the field. Instead, use a cryptographically secure hash function. Heck, even MD-5 is going to be better than anything you try to roll on your own.

      • The worst, by the way, are web sites which require you to pick a super-secure password (at least 12 characters long, must contain punctuation, both upper and lower case letters, a number character, an Egyptian hieroglyph, and must not match the last 15 passwords used in the past and must be changed ever 30 days)--then stores the password and password history as plain text in the user database. Those are the guys I'd love to murder in cold blood.

        No, cold-blood-murder is reserved for sites that do all of the above and also send you a confirmation e-mail containing your password in clear text.

      • Personally I've always liked using some element of a user record attribute as part of the SALT--such as having a UUID associated with each user record that becomes part of the salt for the hash (i.e., HASH(SALT + password + UUID) )--because this means if someone does scrape your database it's computationally a little more difficult to reverse engineer the passwords in the database because even a bunch of people use "123456" as their password, the hashes will be different for each of those users. Of course the UUID must never change or else you'll lock your users out.

        You're supposed to use a new random salt for each password. That's why you store the salt alongside the hashed password in the database.

        • Re: (Score:2)

          by w3woody ( 44457 )
          And this is different from what I described (with the exception of tossing in a separate constant component of the SALT not stored in the database) how, exactly?

          • If you're not talking about using the same salt for each password, then I don't know why you're concerned about multiple users having the same hash simply because they have the same password. The different salts will ensure that they have different hashes even if the passwords are the same.

      • I remember stuff that is easy for humans to remember and let computers generate the hard stuff.

        My slashdot password is echo -n [mysalt]+0100010001010011+slashdot.org | sha265

        The hell if I actually remember that. I could generate it with a piece of paper given enough time. I can generate it on almost any OS I use daily.

        Let mysalt be HorseBatteryStaple. Some inside joke, anything.

  • Use OpenLDAP and Kerberos (Score:4, Informative)

    by Zombie Ryushu ( 803103 ) on Saturday September 12, 2015 @05:43AM (#50508775)

    Use Kerberos with one of the heftier encryption types. Don't use the default Crypt Password type used in Shadow Passwords, and store your accounts in OpenLDAP, not a SQL Database

    • Re: (Score:2)

      by dejanc ( 1528235 )

      Use Kerberos with one of the heftier encryption types. Don't use the default Crypt Password type used in Shadow Passwords, and store your accounts in OpenLDAP, not a SQL Database

      What are the advantages of using OpenLDAP over a SQL database for storing user accounts? Any real world experience that you could share?

      • OpenLDAP (and similar LDAP like Databases are meant for Authorization and Authentication functions. They can use ACLs and are better designed for this use, and th ACLs can make them resistant to data leakage. If you must use a SQL database for other custom things, link some form of User ID in LDAP to a corresponding field in SQL.

    • One important reason you should use something like Kerberos, is the usability. The users will not have a different password on each machine with its own rules and expiration date, etc. This quickly lead to users to write down their passwords on a post-it or use the bad practices to manage the security of their own passwords because they have to periodically change their passwords on many machines. Also, you will have a single or a limited number of password repositories to secure instead of having one on ea

  • Answers (Score:5, Informative)

    by Lord Duran ( 834815 ) on Saturday September 12, 2015 @05:51AM (#50508789)

    Where do I perform hashing (smartphone/web client or server)?
    You hash twice, with different salts - once on the client side and once again (i.e., hash the hash) on the server side. The doubly-salted, doubly-hashed password is the one you store.

    What hash algorithm should I use?
    You said it yourself - bcrypt. bcrypt allows you to set a cost, which increases password brute-forcing difficulty but also increases computational cost on every verification. Set the cost to be the maximum you can handle - if you have a stronger computer and fewer users, you can set a higher cost.

    How do I store the hashes?
    Chrome uses encrypted SQLite for browser saved passwords. Which encryption depends on the platform - Windows has CryptProtectData, KDE and Gnome have keyrings. The basic idea for all of these is to use some symmetric encryption algorithm (e.g. AES) with the key derived from some set of hashes on machine-specific data, like hardware serial numbers. If you want to go hardcore, use a hardware encryption dongle (HSM).
    Note that it is important to encrypt the file on disk, but it is also important to make sure that decrypted hashes stay in server memory for as little as possible.

    How can clients recover forgotten passwords?
    They can't recover forgotten passwords - you're only storing hashes, remember? What they can do is reset their password. Two factor authentication is best (a verified email account and phone number, if you can send SMSes or automated calls), but at least email and a security question seems to be the standard.

    • Re:Answers (Score:4, Insightful)

      by DamonHD ( 794830 ) <d@hd.org> on Saturday September 12, 2015 @07:22AM (#50508959) Homepage

      Security questions IMHO *lower* overall security for a number of reasons and I refuse to use them.

      2FA is a good idea.

      Rgds

      Damon

      • Security questions IMHO *lower* overall security for a number of reasons and I refuse to use them.

        I often don't have a choice, but my bank only knows that my favorite dog's name was #tg57(747R86$vX. "Old Hashy", we'd call him.

        AFAIK, no password vault solutions help the user deal with this kind of nonsense.

        • Re: (Score:2)

          by DamonHD ( 794830 )

          I had a huge argument about this stuff about my bank and whether a fat middle aged bloke should have a favourite colour (and the entropy in the choices anyway) and was explicitly allowed to put rubbish in all the fields and the bank indeed replaced it all with 2FA soon after.

          So sometimes there are choices.

          Rgds

          Damon

          • Why did you have to argue with them? I just key in whatever garbage I feel like in those fields, no need to ask

            • Re: (Score:2)

              by DamonHD ( 794830 )

              Because I wanted the bank staff (and I raised it to a fairly high level) to understand and accept that the 'security questions' could never reasonably used the way that the bank expected, and having gained that insight (and the firestorm of complaint in social media at the time) the bank fixed the issue reasonably well.

              It's not perfect, but the current system works reasonably well.

              So, argument and persuasion rather than just whining seemed to be winning.

              Rgds

              Damon

          • I was disturbed to find out one of my banks doesn't recognise case in its passwords. I put my password in with caps lock on and it worked. Tested a few combinations of upper and lower case all worked.
        • Any password manager that lets you enter arbitrary text (even a single plain-text "notes" field) handles it. It may not auto-fill forms for these, but it can at least record them for later use. You really should never need them auto-filled anyway, since they're just for when you forget your password which you won't because you're using a password manager. I use KeePass which allows me to enter arbitrary key:value pairs. Most sites in my database now have a few entries like Ol' Hashy up there.
          Userid
          Che

    • Re: (Score:2)

      by Soft ( 266615 )

      keyrings [...] key derived from some set of hashes on machine-specific data, like hardware serial numbers. If you want to go hardcore, use a hardware encryption dongle (HSM).

      I'm not an expert, but I'd be wary of storing passwords into a keyring that I can no longer open if some piece of hardware fails. Wouldn't a well-chosen master password be safer?

  • How to handle passwords? Don't. (Score:1)

    by Anonymous Coward

    If at all possible don't do it. Use OpenID, etc. to let someone else have the passwords and worry about that aspect of security. (This is often made user-friendly by showing "Login with Google", etc. for all of the major OpenID providers.) If OpenID or something similar is not an option... then have a really good reason why not. You really don't want to be touching password hashes if you can avoid it.

    If your smartphone app has support for typing in a password on the phone keyboard, something has gone horrib

    • This is often made user-friendly by showing "Login with Google", etc. for all of the major OpenID providers.

      In the era of classic OpenID, the relying party could just provide a field to paste in the user's identifier, and then the login form would take to the provider's site to complete authentication. It was envisioned that users would use the browser's autofill feature to populate the identifier field. But in the era of OpenID Connect, only providers that support Dynamic Client Registration (dyn-reg) support the paste-an-identifier flow, and none of the major providers have chosen to implement dyn-reg. So each

  • At this point every user has at least one SSO since it's baked into google facebook etc etc etc. So the first thing should be to support as many of those as possible especially arbitrary ones, better ones let users do 2 factor auto use sll keys etc etc. Now you will need a fallback local password use ldap never transmit the password over the wire and use a hash thats not known to be insecure.

  • I'm tooting my own horn, but you might find my article on long-term password hashing strategies helpful:

    https://medium.com/@uther_bendragon/sustainable-password-hashing-8c6bd5de3844

    TL;DR version:
    1) Use a one-way collision-resistant algorithm developed by professional cryptographers, and the implementation of which has been adequately studied and understood;
    2) Do not use an algorithm with known vulnerabilities (this obvious step is sometimes not followed);
    3) Use randomly-generated data—salt as addition

    • Re: (Score:2)

      by DamonHD ( 794830 )

      Hmm, yes, when I was putting together security for an online financial system (eg worth stealing credentials for) many years ago, (7) was nagging at me and I might have made do with an upgrade in hash mechanism at next login after a policy change, but yours is nice and/or in combination.

      Rgds

      Damon

      PS. (4) is also an interesting rule-of-thumb, thank you!

  • Allow me to correct this part of your question:

    How can clients recover from forgotten passwords. I'm not saying that using the standard practice of implementing a mechanism whereby a user can reset their own password based on their username and email address is perfectly secure - nothing is - but under no circumstances should a password be retrievable in that manner. Also, the act of a self service password reset should instantly nuke the old.

    • Re: (Score:2)

      by tepples ( 727027 )

      the act of a self service password reset should instantly nuke the old

      I disagree. The old password ought to get nuked when the new one is pasted in twice from your password manager. Otherwise, an attacker can DOS your account by requesting a reset every hour.

  • That's the title of this page [crackstation.net] and I found that to be truth in advertising - it's readable and informative.

  • I think the most important thing to remember on security related topics like this: The answers can get quickly outdated as technology progresses.

    Books might be outdated by the time they appear in print, especially on a lot of practical details. What was considered impossible a few years ago might be done on a machine with a few big GPUs today. Technologies, ideas and theory advance a lot as there is a real war going on in the security field, both by big companies and more shady organisations. All with huge

Slashdot Top Deals

BLISS is ignorance.

Close