Is it better to use an unsuitable hashing algorithm instead of none at all?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
39
down vote

favorite
3












I have to store passwords on a system which doesn't offer any of the algorithms recommended for hashing passwords (e.g. bcrypt, scrypt or PBKDF2). Would it be better to use an unsuitable algorithm (e.g. SHA-1 or SHA-2 family) before using none?




Additional Information: I will be the only one storing passwords on that system, so I can 1) guarantee that none of the passwords will be used twice and 2) ensure that the passwords will have a very high entropy.










share|improve this question



















  • 17




    Do you have the ability to stretch the algorithm - to apply the same algorithm many times? If so, do that at a minimum.
    – Royce Williams
    Nov 19 at 16:13






  • 3




    It seems like you have a high degree of control over the passwords to be stored.. Do you not have a similar level of control over how they are stored? Can you not choose to find something better?
    – Steve-O
    Nov 19 at 18:03






  • 45




    I'm confused. If you're adding the authentication code, how do you not have the ability to pull in a library that implements newer hashing protocols? I'm also wondering if you're doing something like added an admin user to a device that it then distributed? I think this question lacks enough detail to really be answerable. Please provide more details about what you're implementing that will contain the password (a web interface, an IoT device, whatever) and why you need to lock anything down. (If you're distributing a device, then there's no point in even having the password.)
    – jpmc26
    Nov 19 at 21:19







  • 20




    Why do you mention that the pw's are unique? That shouldn't be relevant at all.
    – Daniel F
    Nov 19 at 23:28






  • 23




    Also, ensuring password uniqueness is somehow a flaw rather than a security (if at all): you will have to indicate to a user trying to re-use an existing password that it cannot be used, therefore giving them the indication that this password exists in your database already (or at least this conclusion is easy to come to)
    – Laurent S.
    Nov 20 at 14:07














up vote
39
down vote

favorite
3












I have to store passwords on a system which doesn't offer any of the algorithms recommended for hashing passwords (e.g. bcrypt, scrypt or PBKDF2). Would it be better to use an unsuitable algorithm (e.g. SHA-1 or SHA-2 family) before using none?




Additional Information: I will be the only one storing passwords on that system, so I can 1) guarantee that none of the passwords will be used twice and 2) ensure that the passwords will have a very high entropy.










share|improve this question



















  • 17




    Do you have the ability to stretch the algorithm - to apply the same algorithm many times? If so, do that at a minimum.
    – Royce Williams
    Nov 19 at 16:13






  • 3




    It seems like you have a high degree of control over the passwords to be stored.. Do you not have a similar level of control over how they are stored? Can you not choose to find something better?
    – Steve-O
    Nov 19 at 18:03






  • 45




    I'm confused. If you're adding the authentication code, how do you not have the ability to pull in a library that implements newer hashing protocols? I'm also wondering if you're doing something like added an admin user to a device that it then distributed? I think this question lacks enough detail to really be answerable. Please provide more details about what you're implementing that will contain the password (a web interface, an IoT device, whatever) and why you need to lock anything down. (If you're distributing a device, then there's no point in even having the password.)
    – jpmc26
    Nov 19 at 21:19







  • 20




    Why do you mention that the pw's are unique? That shouldn't be relevant at all.
    – Daniel F
    Nov 19 at 23:28






  • 23




    Also, ensuring password uniqueness is somehow a flaw rather than a security (if at all): you will have to indicate to a user trying to re-use an existing password that it cannot be used, therefore giving them the indication that this password exists in your database already (or at least this conclusion is easy to come to)
    – Laurent S.
    Nov 20 at 14:07












up vote
39
down vote

favorite
3









up vote
39
down vote

favorite
3






3





I have to store passwords on a system which doesn't offer any of the algorithms recommended for hashing passwords (e.g. bcrypt, scrypt or PBKDF2). Would it be better to use an unsuitable algorithm (e.g. SHA-1 or SHA-2 family) before using none?




Additional Information: I will be the only one storing passwords on that system, so I can 1) guarantee that none of the passwords will be used twice and 2) ensure that the passwords will have a very high entropy.










share|improve this question















I have to store passwords on a system which doesn't offer any of the algorithms recommended for hashing passwords (e.g. bcrypt, scrypt or PBKDF2). Would it be better to use an unsuitable algorithm (e.g. SHA-1 or SHA-2 family) before using none?




Additional Information: I will be the only one storing passwords on that system, so I can 1) guarantee that none of the passwords will be used twice and 2) ensure that the passwords will have a very high entropy.







passwords hash






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 19 at 16:01

























asked Nov 19 at 15:16









JFB

340135




340135







  • 17




    Do you have the ability to stretch the algorithm - to apply the same algorithm many times? If so, do that at a minimum.
    – Royce Williams
    Nov 19 at 16:13






  • 3




    It seems like you have a high degree of control over the passwords to be stored.. Do you not have a similar level of control over how they are stored? Can you not choose to find something better?
    – Steve-O
    Nov 19 at 18:03






  • 45




    I'm confused. If you're adding the authentication code, how do you not have the ability to pull in a library that implements newer hashing protocols? I'm also wondering if you're doing something like added an admin user to a device that it then distributed? I think this question lacks enough detail to really be answerable. Please provide more details about what you're implementing that will contain the password (a web interface, an IoT device, whatever) and why you need to lock anything down. (If you're distributing a device, then there's no point in even having the password.)
    – jpmc26
    Nov 19 at 21:19







  • 20




    Why do you mention that the pw's are unique? That shouldn't be relevant at all.
    – Daniel F
    Nov 19 at 23:28






  • 23




    Also, ensuring password uniqueness is somehow a flaw rather than a security (if at all): you will have to indicate to a user trying to re-use an existing password that it cannot be used, therefore giving them the indication that this password exists in your database already (or at least this conclusion is easy to come to)
    – Laurent S.
    Nov 20 at 14:07












  • 17




    Do you have the ability to stretch the algorithm - to apply the same algorithm many times? If so, do that at a minimum.
    – Royce Williams
    Nov 19 at 16:13






  • 3




    It seems like you have a high degree of control over the passwords to be stored.. Do you not have a similar level of control over how they are stored? Can you not choose to find something better?
    – Steve-O
    Nov 19 at 18:03






  • 45




    I'm confused. If you're adding the authentication code, how do you not have the ability to pull in a library that implements newer hashing protocols? I'm also wondering if you're doing something like added an admin user to a device that it then distributed? I think this question lacks enough detail to really be answerable. Please provide more details about what you're implementing that will contain the password (a web interface, an IoT device, whatever) and why you need to lock anything down. (If you're distributing a device, then there's no point in even having the password.)
    – jpmc26
    Nov 19 at 21:19







  • 20




    Why do you mention that the pw's are unique? That shouldn't be relevant at all.
    – Daniel F
    Nov 19 at 23:28






  • 23




    Also, ensuring password uniqueness is somehow a flaw rather than a security (if at all): you will have to indicate to a user trying to re-use an existing password that it cannot be used, therefore giving them the indication that this password exists in your database already (or at least this conclusion is easy to come to)
    – Laurent S.
    Nov 20 at 14:07







17




17




Do you have the ability to stretch the algorithm - to apply the same algorithm many times? If so, do that at a minimum.
– Royce Williams
Nov 19 at 16:13




Do you have the ability to stretch the algorithm - to apply the same algorithm many times? If so, do that at a minimum.
– Royce Williams
Nov 19 at 16:13




3




3




It seems like you have a high degree of control over the passwords to be stored.. Do you not have a similar level of control over how they are stored? Can you not choose to find something better?
– Steve-O
Nov 19 at 18:03




It seems like you have a high degree of control over the passwords to be stored.. Do you not have a similar level of control over how they are stored? Can you not choose to find something better?
– Steve-O
Nov 19 at 18:03




45




45




I'm confused. If you're adding the authentication code, how do you not have the ability to pull in a library that implements newer hashing protocols? I'm also wondering if you're doing something like added an admin user to a device that it then distributed? I think this question lacks enough detail to really be answerable. Please provide more details about what you're implementing that will contain the password (a web interface, an IoT device, whatever) and why you need to lock anything down. (If you're distributing a device, then there's no point in even having the password.)
– jpmc26
Nov 19 at 21:19





I'm confused. If you're adding the authentication code, how do you not have the ability to pull in a library that implements newer hashing protocols? I'm also wondering if you're doing something like added an admin user to a device that it then distributed? I think this question lacks enough detail to really be answerable. Please provide more details about what you're implementing that will contain the password (a web interface, an IoT device, whatever) and why you need to lock anything down. (If you're distributing a device, then there's no point in even having the password.)
– jpmc26
Nov 19 at 21:19





20




20




Why do you mention that the pw's are unique? That shouldn't be relevant at all.
– Daniel F
Nov 19 at 23:28




Why do you mention that the pw's are unique? That shouldn't be relevant at all.
– Daniel F
Nov 19 at 23:28




23




23




Also, ensuring password uniqueness is somehow a flaw rather than a security (if at all): you will have to indicate to a user trying to re-use an existing password that it cannot be used, therefore giving them the indication that this password exists in your database already (or at least this conclusion is easy to come to)
– Laurent S.
Nov 20 at 14:07




Also, ensuring password uniqueness is somehow a flaw rather than a security (if at all): you will have to indicate to a user trying to re-use an existing password that it cannot be used, therefore giving them the indication that this password exists in your database already (or at least this conclusion is easy to come to)
– Laurent S.
Nov 20 at 14:07










12 Answers
12






active

oldest

votes

















up vote
109
down vote













The real answer to your question is simply do not store the passwords there if you cannot properly protect them.



"The system does not support proper password hashing algorithms" is not a valid excuse to compromise the security of your users. Either find a way to properly hash passwords using a strong and properly configured algorithm or do not store them.



But to provide a direct answer to your question: yes, something is better than nothing. SHA-1 or SHA-2 is definitely an improvement over plaintext.



To answer the "then where should the passwords go?" question - Based on the phrasing I am assuming there is a new feature/request for the software that requires the system to store passwords.



If the system cannot properly and securely store passwords (by modern security standards) then I (personally) would reject the request. Intentionally practicing poor security because of legacy system constraints or to appease a business use case is bad security practice. I would inform whoever made the request that I have two viable options:



  1. We have to completely overhaul the system to one that supports modern security practices (such as proper cryptographic password hashing).


  2. I simply cannot add the new feature/request to the existing system for it would compromise security.






share|improve this answer


















  • 8




    @Gherman as with anything, you do a cost/benefit analysis and let the decision-maker and risk owner decide.
    – schroeder
    Nov 19 at 16:46






  • 19




    @dFrancisco refusing to add a new feature is fine if you are the system owner, but you have no basis to refuse if you are the admin or the developer. Advise and educate is your role as a security professional.
    – schroeder
    Nov 19 at 16:47






  • 48




    It would be better to rephrase your refusal in business terms rather than just the vague "security." E.g., "We would be knowingly storing sensitive data in a way that makes it easier for an attacker to obtain it. This may be a violation of GDRP/HIPPA/any-relevant-standard-the-company-might-get-in-trouble-for-breaking and open us up to legal consequences." But this is the correct course of action for generic user management.
    – jpmc26
    Nov 19 at 21:15







  • 20




    While a weak hash is slightly better than nothing, a salted weak hash is significantly better than nothing. Nothing in the question or this answer refer to salting so it's probably a good idea to make a specific mention of that.
    – fluffy
    Nov 20 at 3:36






  • 4




    @Joe I'll give you ROT13, but unsalted MD5 is better than nothing, and salted MD5 is dramatically better than unsalted SHA3.
    – Martin Bonner
    yesterday

















up vote
46
down vote













Yes, a weak cryptographic hash is better than no hash.



The reasons for hashing your passwords are, in the event that your password db is stolen:



  1. Prevent the attacker from trivially obtaining the plaintext passwords.

  2. Prevent the attacker from knowing which users have the same password (this is accomplished via giving each user a unique salt.

1 is an arms race: you want to use a bigger, slower hash function so that it costs the attacker more in electricity to perform the brute-force hash cracking. A single iteration of SHA-1/2 is better than no hash because the attacker has to do some cracking. A single iteration of salted SHA-1/2 will force them to do some cracking without being able to use pre-computed rainbow tables. Moving up to the fancier password hashes (argon2, bcrypt or the older scrypt, pbkdf2) with a higher work factor will crank up the electricity costs of the crack even further.



Using any salted cryptographic hash (even ones not recommended for passwords, like SHA-1, SHA-2) will give the benefits of 2.




At its core, PBKDF2 is just iterated and salted SHA-1/2, so I would do some googling for PBKDF2 implementations, and build your wrapper around SHA-1/2 that emulates it (or better, go all the way and actually implement PBKDF2).






share|improve this answer


















  • 7




    I'd suggest including Argon2 in your list, since it's currently the preferred algorithm when GPUs or FPGA/ASIC cracking are in your threat model (which they should be).
    – Polynomial
    Nov 19 at 15:33






  • 6




    +1. Note that this actually depends on how long your user base is willing to wait for auth (and how much load your auth systems can take in parallel). At the sub-100ms mark, bcrypt is actually more resistant to bruteforce. Only above ~1s/auth does Argon2 become superior. Refs: twitter.com/Sc00bzT/status/1063895918246862848, twitter.com/Sc00bzT/status/1041875128311840768
    – Royce Williams
    Nov 19 at 15:37







  • 1




    Is it really? You tell me you securely store my data, I give you sensitive data to store, you then lose the data because it's not actually secure, wouldn't it be better to be up front and state you're not securely storing the data in the first place? ...idealistically speaking
    – RandomUs1r
    Nov 19 at 22:16






  • 3




    @RandomUs1r What do you mean "not securely storing the data"? PBKDF2, while a bit old, is still considered secure if you use 10,000 iterations of SHA-1 or SHA-2 and unique per-user salts. If you have a SHA-2 primitive available, then you can build PBKDF2 (or something which is functionally equivalent). Please back up your statement that this is only an illusion of security.
    – Mike Ounsworth
    Nov 20 at 13:05







  • 4




    @JFB I think so, but I wouldn't give it to the new hire. Looking at the PBKDF2 spec or an open-source implementation and applying a medium amount of attention to detail would do the trick. Put another way: I would trust myself to implement something PBKDF2-like in a day or two and use it in prod. I would under no circumstances trust myself to implement SHA-2 in under a month.
    – Mike Ounsworth
    2 days ago

















up vote
27
down vote













As others have said, try to find a strong standalone implementation in your platform's language if at all possible.



But if you can't use a strong hash ... then you should definitely still hash your users' passwords, even with a weak hash - because even a weak hash will protect a strong password.



When tools like hashcat can guess billions of passwords per second, weak hashes won't protect weak passwords. But if one of your security-conscious users selects an uncrackable password like 'SDXBZsRVBKVnXznpLTBMIKhTX' or 'afferently-imitatee-snowmelt-heirdom-leeching' ... then even a weak hash like SHA1 will still put that password out of reach of a bruteforce attack.



By using even a weak hash, you can at least enable your savvy users to protect themselves even though your system is weak. (And if you have the ability to stretch - to use the same algorithm thousands of times in a row - this will slow down the attacker as well).



But your savvy users won't be reusing passwords, so even this is of limited value (except for "semi-savvy" users who have picked passwords strong enough to resist bruteforce, but may be reusing that password elsewhere or using a human-parseable password selection scheme ... so using even a weak hash will protect these users as well).



Your best option for all users is to find a way to use a strong hash.



[Edit: the OP has updated the question to indicate that they are the only user of the system, and can set an arbitrarily random password (which seems pretty odd to me; I don't know of a system with such a strange combination of "I am the only user", "I can only pick from a few hashing algorithms", and "All of the hashing algorithms are weak"). Either way, this makes my concern about protecting general users' weak passwords irrelevant for this specific question. Other answers should clarify at the beginning of their answers that they are giving advice that would normally be pretty bad, and is only applicable to this very specific question.]






share|improve this answer






















  • I updated my question with additional information adressing your point of being able to at least protect strong, unique passwords
    – JFB
    Nov 19 at 16:03






  • 2




    Password reuse is when users choose to use the same password across multiple sites (Facebook, their bank, etc.) ... not when two users are using the same password on the same site.
    – Royce Williams
    Nov 19 at 16:15










  • I agree, but with the added caveat that you should NOT use SHA-1 to produce a digest of any sensitive data (like passwords) without using random salt to address password re-use, plus key stretching.
    – Craig
    Nov 19 at 22:54






  • 8




    Upvote for even a weak hash will protect a strong password
    – Kevin Voorn
    Nov 20 at 10:04

















up vote
16
down vote













SHA-2 in this particular case is just as secure as PBKDF/scrypt/bcrypt. Iterations are unnecessary and wasteful. Generate high-entropy (256 bit) passwords and forget about KDFs and even salts.



In fact, it makes more sense to use SHA-2 than PBKDF because there is no existing platform implementation of the algorithm and "rolling your own crypto" is a no-no.



That's quite a strong statement. The essence here in the question is that the OP has full control of the passwords he stores on the system and knows that he will be the only one storing passwords on the system.



Signal makes use of a construction called HKDF in its double-ratchet algorithm, which essentially applies the hashing algorithm for only one iteration.



Why is this okay?



Password KDFs exist for precisely one reason: low-entropy passwords. Most people won't remember a 128- or 256-bit key generated from a CSRNG in their heads. I'd venture that most people can remember at most a 40-bit random string for a long enough period of time to use it.



Pretty much all hash functions (even MD4, MD5, and SHA-1, but since you said you have SHA-2 on the platform, let's be safe here) have a feature called preimage resistance, which is good enough for your application since you control all of the passwords that get stored on your system. This means that it is computationally infeasible, given a hash, to generate something that hashes to the same hash.



Simplifying a bit, the most practical way to generate a preimage for one of these hash functions is to keep trying inputs. There are a few examples of attacks that do slightly better than brute force, but they're totally infeasible. Now, if the password/key you chose to put into the hash function only has 16 bits of entropy, this resistance property won't do you much, because the attacker will be able to try all 65536 different inputs you could have put in.



Why control of the password matters



Think less of the things that you're putting in as "passwords" but more as cryptographic keys. As long as you are hashing keys that have entropy greater than or equal to the number of bits output by your choice of hash function (for SHA-256, that's 256 bits), then you're totally fine just running one iteration of the hash over it to prevent key extraction. The preimage resistance of the hash combined with the high entropy of your key means that an attacker simply cannot guess the value that you put in. There's no need for the thousands of iterations or arguing with the business side or reasoning about an abstract attack to not-so-receptive bosses. FPGA/ASIC resistance is a moot point when you have to guess a 256-bit input into the hash function.



Recommendations



Generate your "passwords" with a hardware RNG or a CSPRNG and promptly destroy any seed material that could be used to recover any internal state and therefore the passwords. Make sure that these are 256 bits long. If your system doesn't support non-alphanumeric or non-ASCII passwords, then after you generate the 256 bits, encode it in base-64 or base-26 or binary if you like. (This means that the actual passwords that you submit will be longer than 32 bytes, but this doesn't help entropy much.)



Treat these passwords like cryptographic keys -- ideally, they would be stored on hardware tokens. A hardware password manager works very well for this purpose. Store the SHA-256 hashes in your system, and verify the passwords by hashing and comparing. You should reject all attempted passwords that do not match your generation criterion (an example would be a user-selected password < 256 bits), even if the hashes match, and you should not allow anyone to set a password that did not come from a CSRNG. This should be
documented. Even better is if you add some obscure checksum byte at the end of the passwords that you generate that is verified by the platform before it allows you to set the password. This should deter all but the most hilariously incompetent people from putting anything less than a cryptographic key on your platform.



Public Key Cryptography



Your use case is a bit odd. Most places maintain passwords because setting up a PKI and dealing with end-users is very difficult, especially with things like public keys. Since you seem to be the only one entering passwords into the system, maybe it would make more sense to store Ed25519 or ECDSA public keys on the system and write code there that implements a challenge-response protocol (a simple one is sign this 256-bit value -- but be careful that you don't reuse these keys, as someone might trick you into signing away your Bitcoin or a criminal confession). The device that would interface with your system here and maintain the private keys probably has a strong implementation of public-key cryptography and would have no problem authenticating itself. Your "roll my own" implementation of the signature verification could be the least secure in the world in terms of side-channel attacks (think of putting its entire state on a billboard or the blockchain), as long as it gives the correct answer, and you would be perfectly fine, as the verification algorithm simply has no access to the private keys.






share|improve this answer










New contributor




John Adams is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.













  • 2




    I ... um ... Most of this answer appears to be about completely unrelated cryptography topics and/or highly misguided. The remainder is disconnected from how password-storage techniques actually work. Salting and iterations are 100% how passwords are securely stored. Further, recommending that someone use straight SHA-2 is very bad advice; my 6x 1080 rig can guess 18.7 billion passwords per second of SHA-2, but only 95,000 per second of bcrypt cost 5 (and bcrypt cost 12 or higher is the current modern target)
    – Royce Williams
    Nov 20 at 5:48







  • 8




    @RoyceWilliams I'm not a security professional, but if I understand OP correctly, they're advocating that users put in no less then 256 bits of entropy for passwords. Even at your 18.7 billion attempts a second, if my back of the napkin math is correct ((2^256) / 18.700.000.000 / 60 / 60 / 24 / 365) then you'd still need 1.963*e+59 years to try all combinations, which I think would qualify as "computationally infeasible" even if you assume that highly optimized hardware would be 100.000 times more efficient.
    – Magisch
    Nov 20 at 12:20






  • 2




    In other words, to a non security professional like me, it would seem that the answerer is correct in that every preimage resistant hashing algorhitm could be considered safe if you can guarantee non reused 256 bit entropy passwords.
    – Magisch
    Nov 20 at 12:29






  • 1




    To put it simply, very long, securely generated passwords are essentially what cryptographic keys are.
    – John Adams
    Nov 20 at 22:10






  • 6




    @RoyceWilliams You seem to misunderstand the gist of the answer. If your passwords have enough entropy, then a KDF is unnecessary. KDFs are used because most passwords are low-entropy. When your passwords get to entropy levels comparable to those of cryptographic keys, it really doesn't matter how they're hashed, as long as the hash has preimage resistance.
    – John Adams
    Nov 20 at 22:15

















up vote
3
down vote













I agree with Mike and Royce in their answers, and don't feel the need to repeat what they covered well. However I wanted to more directly address this comment of yours:




Additional Information: I will be the only one storing passwords on
that system, so I can 1) guarantee that none of the passwords will be
used twice and 2) ensure that the passwords will have a very high
entropy.




This piece of information is both important and not-important. Here's why:



The case for password hashing



It's always important to remember why we hash passwords, and it all boils down to password reuse. The reason why password hashing is so important is because when your system gets compromised and passwords are stolen, it isn't just access to your site that is compromised, but access to every site where your users have re-used the same email/password combination which (as we know) happens a lot. Password hashing is about protecting users from themselves. If absolutely everyone used strong and unique passwords on every site, then password hashing would be a lot less necessary. It would still have some value because there are use cases where a hacker might gain read-only access to a database dump, so hashed passwords can provide some protection against attackers getting actual access to your system in. However, if people used strong and unique passwords everywhere then password hashing would become more of a secondary concern instead of the absolutely-critical necessity it is today.



So, if you can guarantee that every user of your system will only ever use strong and unique passwords (i.e. passwords that have not been used on other sites), then I think that even something simple like SHA2 would actually be a perfectly reasonable choice, regardless of whether or not better functions were available.



BUT: changing business needs



However, I would encourage you to double check your assumptions (that strong unique passwords will be the only ones ever in your system). I've seen business needs change to often in the past to rely on assumptions like that in critical business areas (which this may not be - obviously I don't know what this does). The problem is that business needs change. Maybe it's just me, but in my experience things that were meant to be temporary or limited to just a couple people inevitably turn into critical business applications used by everyone in the company, and all of a sudden you have a weak password scheme protecting critical business infrastructure. It won't always happen because people are trying to cut corners, but because 12 months down the road you forget that you didn't use a great password hash, or you leave and then next guy doesn't look into it, or you're under pressure to meet a deadline and you forget, or, or, or...



In my experience businesses end up having security breaches not because security is hard but because they don't understand the need for spending time (aka money) on good security practices and cut corners where they shouldn't. Sure, right now a great password hashing scheme doesn't matter, but can you really guarantee that that won't change in the future? If you don't have time to put in proper password hashing now, can you guarantee that when the needs change and it suddenly does matter, that you will have time to do it right then?



Of course at the end of the day every business needs to make money, and sometimes "Let's keep this simple for now to get this out the door" is a perfectly reasonable answer. Just be careful though because making that decision too often is how companies end up with systems filled with security holes. As a company you have to find that balance for yourself. The trouble is that when companies chronically skimp on the security it is ultimately their customers that hurt the most.






share|improve this answer




















  • +1 for "things that were meant to be temporary or limited to just a couple people inevitably turn into critical business applications"
    – Kelly Bang
    Nov 20 at 21:23

















up vote
2
down vote














I have to store passwords on a system which doesn't offer any of the algorithms recommended for hashing passwords (e.g. bcrypt, scrypt or PBKDF2). Would it be better to use an unsuitable algorithm (e.g. SHA-1 or SHA-2 family) before using none?




The strict answer to your question is yes. The reason is that fast hashes won't protect weak passwords, but they will protect very strong ones, and that is strictly better than plaintext.



However, if you have SHA-1 or SHA-2 there are are very few (if any!) excuses not to use PBKDF2. Yeah, the common advice is "don't roll your own crypto," but if you've got SHA-1 or SHA-2 that's already the key building block for PBKDF2, and for the case of password hashing writing your own implementation of PBKDF2 can hardly be worse than not. Here's the relevant RFC and section:



  • https://tools.ietf.org/html/rfc2898#section-5.2

When they say "pseudorandom function" you should use some HMAC variant (ideally HMAC-SHA-512, but any of them will do). Your library likely already has HMAC implementations, but if it doesn't, password hashing is again a case where implementing your own can't be worse than not.






share|improve this answer



























    up vote
    1
    down vote













    To answer your question: yes, use the best algorithm you have access to. If you have several, you might combine them (note: concatenation of passwords, e.g. sha1(password)+md5sum(password), is more vulnerable to guessing, since an attacker could pick which hash they want to guess, but collisions are much less likely, since both passwords have to match. Do use random, different salt for each password.



    You say your system "doesn't offer any of the algorithms recommended for hashing passwords". I would encourage you to reexamine that assumption.



    Almost every modern programming language has implementations of secure hashes. You do not necessarily need it implemented in a pre-made, pre-installed library - for example, if your program is written in C, you should be able to find implementations of any hash in C, as a stand-alone function. Even tiny processors like Arduino have bcrypt and PBKDF2, off the shelf. The extra labour involved is minimal. You could even implement it yourself (but be very careful, and test very thoroughly!).



    I do not doubt that there are exceptions, but there aren't many.






    share|improve this answer



























      up vote
      0
      down vote













      YES, even low quality hash is much better than storing passwords in plaintext



      If I understand you update, someone else will be doing the authentication (unrelated to you and your database), and you will use your password hash database only for duplicate password detection? Requirement of determining the password entropy would be based on plaintext, and is unrelated to storing password hashes, right?



      Then you can store in your hash database just a small part of calculated sha2 hash of salt+plaintext (for example, storing only low 8 bytes of 32 bytes returned by sha256), which will be plenty enough to detect duplicates with no false positives in real life, but still not enough to allow the attacker to use rainbow tables to guess original password in case your database is stolen.



      (Disclaimer: if you ARE doing authentication and not only duplicate password detection, than dropping part ot the hash would obviously be terrible idea!)






      share|improve this answer



























        up vote
        0
        down vote













        Yes, using a weak hash is better than none.



        I think you should also consider the administrative way. If you maintain the database (but are not allowed to change the structure, who knows why...) you should not see plain text passwords, even if you are the most integer person and would not do any harm with that information. Just like the proverb: Opportunity makes the thief.






        share|improve this answer








        New contributor




        Lithilion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.
























          up vote
          0
          down vote













          Yes, it's definitively better to use a simple hash than none (though seeing how you apparently implement the system, I fail to see what's hindering you from doing things properly).



          However, given your "Additional information" edit, one might so bold as to say that you do not even need salt! That doesn't mean it's a good design and I wouldn't recommend that, but if you are serious about your guarantees, a simple secure hash of reasonable size is enough, strictly speaking.



          Why does one make such a fuss about password storage in the first place? Usually, passwords are low-entropy, and even when hashed there's a fair chance of guessing a password, even moreso as hash functions are very fast, trivially parallelizable, and there exist rainbow tables which provide a cheap shortcut. So even being unreadable after being hashed, this doesn't necessarily mean that passwords are unrecoverable.

          In principle, given infinite time, you could recover every password on every system (or at least a password that will work). That's just a consequence of the fact that there is a finite number of outputs to a hash function. So, in a quasi-exhaustive search, some input sequence must necessarily produce an output that works.

          Luckily attackers do not have infinite time, so our job is to make sure they don't have a reasonable chance of finding an input sequence that works within finite time, and with a finite supply of energy.



          Now... you say that you are the only user and you can guarantee that passwords are random and high entropy. This rules out most of the concerns about guessing.



          Given a "reasonable" digest size, that means that the chance of finding the hash in a rainbow table is minimal (zero, more or less), and the chance of finding it by brute force is equally more or less zero. There's no way someone will break SHA-256 digest brute force, let alone SHA-512. That idea simply isn't compatible with our understanding of how physics work.

          If the digest is large enough, and passwords are guaranteed (as you state) to be unique, random, high entropy... then actually you're just good to go with hashing once.



          Now of course, normally a system should work reliably even if you cannot provide that guarantee (or any guarantee for that matter). Thus, it's not the very best design.






          share|improve this answer



























            up vote
            0
            down vote













            Yeah you should be fine. SHA1 and 2 are still pretty strong for storing high entropy password hashes and will provide adequate protection from brute forcing. SHA2 provides better protection than SHA1.The vulnerabilities in SHA2 arn't relevant for this scenario since they relate to creating collisions where the initial plaintext is already known.






            share|improve this answer








            New contributor




            Jake is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.
























              up vote
              0
              down vote













              To go along with the excellent answers above, I want to give a complimentary but contrary answer:



              No. Using a weak hash is worse than not using a hash at all.



              A weak hash gives you the illusion of security.



              While you and your managers might understand currently that the hash offers no real security, a manager or developer down the line may think the hash is secure. These people may decide to store additional information using the hash in question.



              There is also the risk where management may not simply understand that the hash is not secure to begin with. When faced with a decision to invest in security development, they may decide "the current system is good enough" because it is hashed already, and hashing is considered best practice.






              share|improve this answer








              New contributor




              Gregroy Currie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
              Check out our Code of Conduct.

















                Your Answer








                StackExchange.ready(function()
                var channelOptions =
                tags: "".split(" "),
                id: "162"
                ;
                initTagRenderer("".split(" "), "".split(" "), channelOptions);

                StackExchange.using("externalEditor", function()
                // Have to fire editor after snippets, if snippets enabled
                if (StackExchange.settings.snippets.snippetsEnabled)
                StackExchange.using("snippets", function()
                createEditor();
                );

                else
                createEditor();

                );

                function createEditor()
                StackExchange.prepareEditor(
                heartbeatType: 'answer',
                convertImagesToLinks: false,
                noModals: true,
                showLowRepImageUploadWarning: true,
                reputationToPostImages: null,
                bindNavPrevention: true,
                postfix: "",
                imageUploader:
                brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
                contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
                allowUrls: true
                ,
                noCode: true, onDemand: true,
                discardSelector: ".discard-answer"
                ,immediatelyShowMarkdownHelp:true
                );



                );













                 

                draft saved


                draft discarded


















                StackExchange.ready(
                function ()
                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f197994%2fis-it-better-to-use-an-unsuitable-hashing-algorithm-instead-of-none-at-all%23new-answer', 'question_page');

                );

                Post as a guest















                Required, but never shown

























                12 Answers
                12






                active

                oldest

                votes








                12 Answers
                12






                active

                oldest

                votes









                active

                oldest

                votes






                active

                oldest

                votes








                up vote
                109
                down vote













                The real answer to your question is simply do not store the passwords there if you cannot properly protect them.



                "The system does not support proper password hashing algorithms" is not a valid excuse to compromise the security of your users. Either find a way to properly hash passwords using a strong and properly configured algorithm or do not store them.



                But to provide a direct answer to your question: yes, something is better than nothing. SHA-1 or SHA-2 is definitely an improvement over plaintext.



                To answer the "then where should the passwords go?" question - Based on the phrasing I am assuming there is a new feature/request for the software that requires the system to store passwords.



                If the system cannot properly and securely store passwords (by modern security standards) then I (personally) would reject the request. Intentionally practicing poor security because of legacy system constraints or to appease a business use case is bad security practice. I would inform whoever made the request that I have two viable options:



                1. We have to completely overhaul the system to one that supports modern security practices (such as proper cryptographic password hashing).


                2. I simply cannot add the new feature/request to the existing system for it would compromise security.






                share|improve this answer


















                • 8




                  @Gherman as with anything, you do a cost/benefit analysis and let the decision-maker and risk owner decide.
                  – schroeder
                  Nov 19 at 16:46






                • 19




                  @dFrancisco refusing to add a new feature is fine if you are the system owner, but you have no basis to refuse if you are the admin or the developer. Advise and educate is your role as a security professional.
                  – schroeder
                  Nov 19 at 16:47






                • 48




                  It would be better to rephrase your refusal in business terms rather than just the vague "security." E.g., "We would be knowingly storing sensitive data in a way that makes it easier for an attacker to obtain it. This may be a violation of GDRP/HIPPA/any-relevant-standard-the-company-might-get-in-trouble-for-breaking and open us up to legal consequences." But this is the correct course of action for generic user management.
                  – jpmc26
                  Nov 19 at 21:15







                • 20




                  While a weak hash is slightly better than nothing, a salted weak hash is significantly better than nothing. Nothing in the question or this answer refer to salting so it's probably a good idea to make a specific mention of that.
                  – fluffy
                  Nov 20 at 3:36






                • 4




                  @Joe I'll give you ROT13, but unsalted MD5 is better than nothing, and salted MD5 is dramatically better than unsalted SHA3.
                  – Martin Bonner
                  yesterday














                up vote
                109
                down vote













                The real answer to your question is simply do not store the passwords there if you cannot properly protect them.



                "The system does not support proper password hashing algorithms" is not a valid excuse to compromise the security of your users. Either find a way to properly hash passwords using a strong and properly configured algorithm or do not store them.



                But to provide a direct answer to your question: yes, something is better than nothing. SHA-1 or SHA-2 is definitely an improvement over plaintext.



                To answer the "then where should the passwords go?" question - Based on the phrasing I am assuming there is a new feature/request for the software that requires the system to store passwords.



                If the system cannot properly and securely store passwords (by modern security standards) then I (personally) would reject the request. Intentionally practicing poor security because of legacy system constraints or to appease a business use case is bad security practice. I would inform whoever made the request that I have two viable options:



                1. We have to completely overhaul the system to one that supports modern security practices (such as proper cryptographic password hashing).


                2. I simply cannot add the new feature/request to the existing system for it would compromise security.






                share|improve this answer


















                • 8




                  @Gherman as with anything, you do a cost/benefit analysis and let the decision-maker and risk owner decide.
                  – schroeder
                  Nov 19 at 16:46






                • 19




                  @dFrancisco refusing to add a new feature is fine if you are the system owner, but you have no basis to refuse if you are the admin or the developer. Advise and educate is your role as a security professional.
                  – schroeder
                  Nov 19 at 16:47






                • 48




                  It would be better to rephrase your refusal in business terms rather than just the vague "security." E.g., "We would be knowingly storing sensitive data in a way that makes it easier for an attacker to obtain it. This may be a violation of GDRP/HIPPA/any-relevant-standard-the-company-might-get-in-trouble-for-breaking and open us up to legal consequences." But this is the correct course of action for generic user management.
                  – jpmc26
                  Nov 19 at 21:15







                • 20




                  While a weak hash is slightly better than nothing, a salted weak hash is significantly better than nothing. Nothing in the question or this answer refer to salting so it's probably a good idea to make a specific mention of that.
                  – fluffy
                  Nov 20 at 3:36






                • 4




                  @Joe I'll give you ROT13, but unsalted MD5 is better than nothing, and salted MD5 is dramatically better than unsalted SHA3.
                  – Martin Bonner
                  yesterday












                up vote
                109
                down vote










                up vote
                109
                down vote









                The real answer to your question is simply do not store the passwords there if you cannot properly protect them.



                "The system does not support proper password hashing algorithms" is not a valid excuse to compromise the security of your users. Either find a way to properly hash passwords using a strong and properly configured algorithm or do not store them.



                But to provide a direct answer to your question: yes, something is better than nothing. SHA-1 or SHA-2 is definitely an improvement over plaintext.



                To answer the "then where should the passwords go?" question - Based on the phrasing I am assuming there is a new feature/request for the software that requires the system to store passwords.



                If the system cannot properly and securely store passwords (by modern security standards) then I (personally) would reject the request. Intentionally practicing poor security because of legacy system constraints or to appease a business use case is bad security practice. I would inform whoever made the request that I have two viable options:



                1. We have to completely overhaul the system to one that supports modern security practices (such as proper cryptographic password hashing).


                2. I simply cannot add the new feature/request to the existing system for it would compromise security.






                share|improve this answer














                The real answer to your question is simply do not store the passwords there if you cannot properly protect them.



                "The system does not support proper password hashing algorithms" is not a valid excuse to compromise the security of your users. Either find a way to properly hash passwords using a strong and properly configured algorithm or do not store them.



                But to provide a direct answer to your question: yes, something is better than nothing. SHA-1 or SHA-2 is definitely an improvement over plaintext.



                To answer the "then where should the passwords go?" question - Based on the phrasing I am assuming there is a new feature/request for the software that requires the system to store passwords.



                If the system cannot properly and securely store passwords (by modern security standards) then I (personally) would reject the request. Intentionally practicing poor security because of legacy system constraints or to appease a business use case is bad security practice. I would inform whoever made the request that I have two viable options:



                1. We have to completely overhaul the system to one that supports modern security practices (such as proper cryptographic password hashing).


                2. I simply cannot add the new feature/request to the existing system for it would compromise security.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited 2 days ago









                Robert Harvey

                1469




                1469










                answered Nov 19 at 15:22









                dFrancisco

                2,3851424




                2,3851424







                • 8




                  @Gherman as with anything, you do a cost/benefit analysis and let the decision-maker and risk owner decide.
                  – schroeder
                  Nov 19 at 16:46






                • 19




                  @dFrancisco refusing to add a new feature is fine if you are the system owner, but you have no basis to refuse if you are the admin or the developer. Advise and educate is your role as a security professional.
                  – schroeder
                  Nov 19 at 16:47






                • 48




                  It would be better to rephrase your refusal in business terms rather than just the vague "security." E.g., "We would be knowingly storing sensitive data in a way that makes it easier for an attacker to obtain it. This may be a violation of GDRP/HIPPA/any-relevant-standard-the-company-might-get-in-trouble-for-breaking and open us up to legal consequences." But this is the correct course of action for generic user management.
                  – jpmc26
                  Nov 19 at 21:15







                • 20




                  While a weak hash is slightly better than nothing, a salted weak hash is significantly better than nothing. Nothing in the question or this answer refer to salting so it's probably a good idea to make a specific mention of that.
                  – fluffy
                  Nov 20 at 3:36






                • 4




                  @Joe I'll give you ROT13, but unsalted MD5 is better than nothing, and salted MD5 is dramatically better than unsalted SHA3.
                  – Martin Bonner
                  yesterday












                • 8




                  @Gherman as with anything, you do a cost/benefit analysis and let the decision-maker and risk owner decide.
                  – schroeder
                  Nov 19 at 16:46






                • 19




                  @dFrancisco refusing to add a new feature is fine if you are the system owner, but you have no basis to refuse if you are the admin or the developer. Advise and educate is your role as a security professional.
                  – schroeder
                  Nov 19 at 16:47






                • 48




                  It would be better to rephrase your refusal in business terms rather than just the vague "security." E.g., "We would be knowingly storing sensitive data in a way that makes it easier for an attacker to obtain it. This may be a violation of GDRP/HIPPA/any-relevant-standard-the-company-might-get-in-trouble-for-breaking and open us up to legal consequences." But this is the correct course of action for generic user management.
                  – jpmc26
                  Nov 19 at 21:15







                • 20




                  While a weak hash is slightly better than nothing, a salted weak hash is significantly better than nothing. Nothing in the question or this answer refer to salting so it's probably a good idea to make a specific mention of that.
                  – fluffy
                  Nov 20 at 3:36






                • 4




                  @Joe I'll give you ROT13, but unsalted MD5 is better than nothing, and salted MD5 is dramatically better than unsalted SHA3.
                  – Martin Bonner
                  yesterday







                8




                8




                @Gherman as with anything, you do a cost/benefit analysis and let the decision-maker and risk owner decide.
                – schroeder
                Nov 19 at 16:46




                @Gherman as with anything, you do a cost/benefit analysis and let the decision-maker and risk owner decide.
                – schroeder
                Nov 19 at 16:46




                19




                19




                @dFrancisco refusing to add a new feature is fine if you are the system owner, but you have no basis to refuse if you are the admin or the developer. Advise and educate is your role as a security professional.
                – schroeder
                Nov 19 at 16:47




                @dFrancisco refusing to add a new feature is fine if you are the system owner, but you have no basis to refuse if you are the admin or the developer. Advise and educate is your role as a security professional.
                – schroeder
                Nov 19 at 16:47




                48




                48




                It would be better to rephrase your refusal in business terms rather than just the vague "security." E.g., "We would be knowingly storing sensitive data in a way that makes it easier for an attacker to obtain it. This may be a violation of GDRP/HIPPA/any-relevant-standard-the-company-might-get-in-trouble-for-breaking and open us up to legal consequences." But this is the correct course of action for generic user management.
                – jpmc26
                Nov 19 at 21:15





                It would be better to rephrase your refusal in business terms rather than just the vague "security." E.g., "We would be knowingly storing sensitive data in a way that makes it easier for an attacker to obtain it. This may be a violation of GDRP/HIPPA/any-relevant-standard-the-company-might-get-in-trouble-for-breaking and open us up to legal consequences." But this is the correct course of action for generic user management.
                – jpmc26
                Nov 19 at 21:15





                20




                20




                While a weak hash is slightly better than nothing, a salted weak hash is significantly better than nothing. Nothing in the question or this answer refer to salting so it's probably a good idea to make a specific mention of that.
                – fluffy
                Nov 20 at 3:36




                While a weak hash is slightly better than nothing, a salted weak hash is significantly better than nothing. Nothing in the question or this answer refer to salting so it's probably a good idea to make a specific mention of that.
                – fluffy
                Nov 20 at 3:36




                4




                4




                @Joe I'll give you ROT13, but unsalted MD5 is better than nothing, and salted MD5 is dramatically better than unsalted SHA3.
                – Martin Bonner
                yesterday




                @Joe I'll give you ROT13, but unsalted MD5 is better than nothing, and salted MD5 is dramatically better than unsalted SHA3.
                – Martin Bonner
                yesterday












                up vote
                46
                down vote













                Yes, a weak cryptographic hash is better than no hash.



                The reasons for hashing your passwords are, in the event that your password db is stolen:



                1. Prevent the attacker from trivially obtaining the plaintext passwords.

                2. Prevent the attacker from knowing which users have the same password (this is accomplished via giving each user a unique salt.

                1 is an arms race: you want to use a bigger, slower hash function so that it costs the attacker more in electricity to perform the brute-force hash cracking. A single iteration of SHA-1/2 is better than no hash because the attacker has to do some cracking. A single iteration of salted SHA-1/2 will force them to do some cracking without being able to use pre-computed rainbow tables. Moving up to the fancier password hashes (argon2, bcrypt or the older scrypt, pbkdf2) with a higher work factor will crank up the electricity costs of the crack even further.



                Using any salted cryptographic hash (even ones not recommended for passwords, like SHA-1, SHA-2) will give the benefits of 2.




                At its core, PBKDF2 is just iterated and salted SHA-1/2, so I would do some googling for PBKDF2 implementations, and build your wrapper around SHA-1/2 that emulates it (or better, go all the way and actually implement PBKDF2).






                share|improve this answer


















                • 7




                  I'd suggest including Argon2 in your list, since it's currently the preferred algorithm when GPUs or FPGA/ASIC cracking are in your threat model (which they should be).
                  – Polynomial
                  Nov 19 at 15:33






                • 6




                  +1. Note that this actually depends on how long your user base is willing to wait for auth (and how much load your auth systems can take in parallel). At the sub-100ms mark, bcrypt is actually more resistant to bruteforce. Only above ~1s/auth does Argon2 become superior. Refs: twitter.com/Sc00bzT/status/1063895918246862848, twitter.com/Sc00bzT/status/1041875128311840768
                  – Royce Williams
                  Nov 19 at 15:37







                • 1




                  Is it really? You tell me you securely store my data, I give you sensitive data to store, you then lose the data because it's not actually secure, wouldn't it be better to be up front and state you're not securely storing the data in the first place? ...idealistically speaking
                  – RandomUs1r
                  Nov 19 at 22:16






                • 3




                  @RandomUs1r What do you mean "not securely storing the data"? PBKDF2, while a bit old, is still considered secure if you use 10,000 iterations of SHA-1 or SHA-2 and unique per-user salts. If you have a SHA-2 primitive available, then you can build PBKDF2 (or something which is functionally equivalent). Please back up your statement that this is only an illusion of security.
                  – Mike Ounsworth
                  Nov 20 at 13:05







                • 4




                  @JFB I think so, but I wouldn't give it to the new hire. Looking at the PBKDF2 spec or an open-source implementation and applying a medium amount of attention to detail would do the trick. Put another way: I would trust myself to implement something PBKDF2-like in a day or two and use it in prod. I would under no circumstances trust myself to implement SHA-2 in under a month.
                  – Mike Ounsworth
                  2 days ago














                up vote
                46
                down vote













                Yes, a weak cryptographic hash is better than no hash.



                The reasons for hashing your passwords are, in the event that your password db is stolen:



                1. Prevent the attacker from trivially obtaining the plaintext passwords.

                2. Prevent the attacker from knowing which users have the same password (this is accomplished via giving each user a unique salt.

                1 is an arms race: you want to use a bigger, slower hash function so that it costs the attacker more in electricity to perform the brute-force hash cracking. A single iteration of SHA-1/2 is better than no hash because the attacker has to do some cracking. A single iteration of salted SHA-1/2 will force them to do some cracking without being able to use pre-computed rainbow tables. Moving up to the fancier password hashes (argon2, bcrypt or the older scrypt, pbkdf2) with a higher work factor will crank up the electricity costs of the crack even further.



                Using any salted cryptographic hash (even ones not recommended for passwords, like SHA-1, SHA-2) will give the benefits of 2.




                At its core, PBKDF2 is just iterated and salted SHA-1/2, so I would do some googling for PBKDF2 implementations, and build your wrapper around SHA-1/2 that emulates it (or better, go all the way and actually implement PBKDF2).






                share|improve this answer


















                • 7




                  I'd suggest including Argon2 in your list, since it's currently the preferred algorithm when GPUs or FPGA/ASIC cracking are in your threat model (which they should be).
                  – Polynomial
                  Nov 19 at 15:33






                • 6




                  +1. Note that this actually depends on how long your user base is willing to wait for auth (and how much load your auth systems can take in parallel). At the sub-100ms mark, bcrypt is actually more resistant to bruteforce. Only above ~1s/auth does Argon2 become superior. Refs: twitter.com/Sc00bzT/status/1063895918246862848, twitter.com/Sc00bzT/status/1041875128311840768
                  – Royce Williams
                  Nov 19 at 15:37







                • 1




                  Is it really? You tell me you securely store my data, I give you sensitive data to store, you then lose the data because it's not actually secure, wouldn't it be better to be up front and state you're not securely storing the data in the first place? ...idealistically speaking
                  – RandomUs1r
                  Nov 19 at 22:16






                • 3




                  @RandomUs1r What do you mean "not securely storing the data"? PBKDF2, while a bit old, is still considered secure if you use 10,000 iterations of SHA-1 or SHA-2 and unique per-user salts. If you have a SHA-2 primitive available, then you can build PBKDF2 (or something which is functionally equivalent). Please back up your statement that this is only an illusion of security.
                  – Mike Ounsworth
                  Nov 20 at 13:05







                • 4




                  @JFB I think so, but I wouldn't give it to the new hire. Looking at the PBKDF2 spec or an open-source implementation and applying a medium amount of attention to detail would do the trick. Put another way: I would trust myself to implement something PBKDF2-like in a day or two and use it in prod. I would under no circumstances trust myself to implement SHA-2 in under a month.
                  – Mike Ounsworth
                  2 days ago












                up vote
                46
                down vote










                up vote
                46
                down vote









                Yes, a weak cryptographic hash is better than no hash.



                The reasons for hashing your passwords are, in the event that your password db is stolen:



                1. Prevent the attacker from trivially obtaining the plaintext passwords.

                2. Prevent the attacker from knowing which users have the same password (this is accomplished via giving each user a unique salt.

                1 is an arms race: you want to use a bigger, slower hash function so that it costs the attacker more in electricity to perform the brute-force hash cracking. A single iteration of SHA-1/2 is better than no hash because the attacker has to do some cracking. A single iteration of salted SHA-1/2 will force them to do some cracking without being able to use pre-computed rainbow tables. Moving up to the fancier password hashes (argon2, bcrypt or the older scrypt, pbkdf2) with a higher work factor will crank up the electricity costs of the crack even further.



                Using any salted cryptographic hash (even ones not recommended for passwords, like SHA-1, SHA-2) will give the benefits of 2.




                At its core, PBKDF2 is just iterated and salted SHA-1/2, so I would do some googling for PBKDF2 implementations, and build your wrapper around SHA-1/2 that emulates it (or better, go all the way and actually implement PBKDF2).






                share|improve this answer














                Yes, a weak cryptographic hash is better than no hash.



                The reasons for hashing your passwords are, in the event that your password db is stolen:



                1. Prevent the attacker from trivially obtaining the plaintext passwords.

                2. Prevent the attacker from knowing which users have the same password (this is accomplished via giving each user a unique salt.

                1 is an arms race: you want to use a bigger, slower hash function so that it costs the attacker more in electricity to perform the brute-force hash cracking. A single iteration of SHA-1/2 is better than no hash because the attacker has to do some cracking. A single iteration of salted SHA-1/2 will force them to do some cracking without being able to use pre-computed rainbow tables. Moving up to the fancier password hashes (argon2, bcrypt or the older scrypt, pbkdf2) with a higher work factor will crank up the electricity costs of the crack even further.



                Using any salted cryptographic hash (even ones not recommended for passwords, like SHA-1, SHA-2) will give the benefits of 2.




                At its core, PBKDF2 is just iterated and salted SHA-1/2, so I would do some googling for PBKDF2 implementations, and build your wrapper around SHA-1/2 that emulates it (or better, go all the way and actually implement PBKDF2).







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited 2 days ago

























                answered Nov 19 at 15:28









                Mike Ounsworth

                37.7k1487134




                37.7k1487134







                • 7




                  I'd suggest including Argon2 in your list, since it's currently the preferred algorithm when GPUs or FPGA/ASIC cracking are in your threat model (which they should be).
                  – Polynomial
                  Nov 19 at 15:33






                • 6




                  +1. Note that this actually depends on how long your user base is willing to wait for auth (and how much load your auth systems can take in parallel). At the sub-100ms mark, bcrypt is actually more resistant to bruteforce. Only above ~1s/auth does Argon2 become superior. Refs: twitter.com/Sc00bzT/status/1063895918246862848, twitter.com/Sc00bzT/status/1041875128311840768
                  – Royce Williams
                  Nov 19 at 15:37







                • 1




                  Is it really? You tell me you securely store my data, I give you sensitive data to store, you then lose the data because it's not actually secure, wouldn't it be better to be up front and state you're not securely storing the data in the first place? ...idealistically speaking
                  – RandomUs1r
                  Nov 19 at 22:16






                • 3




                  @RandomUs1r What do you mean "not securely storing the data"? PBKDF2, while a bit old, is still considered secure if you use 10,000 iterations of SHA-1 or SHA-2 and unique per-user salts. If you have a SHA-2 primitive available, then you can build PBKDF2 (or something which is functionally equivalent). Please back up your statement that this is only an illusion of security.
                  – Mike Ounsworth
                  Nov 20 at 13:05







                • 4




                  @JFB I think so, but I wouldn't give it to the new hire. Looking at the PBKDF2 spec or an open-source implementation and applying a medium amount of attention to detail would do the trick. Put another way: I would trust myself to implement something PBKDF2-like in a day or two and use it in prod. I would under no circumstances trust myself to implement SHA-2 in under a month.
                  – Mike Ounsworth
                  2 days ago












                • 7




                  I'd suggest including Argon2 in your list, since it's currently the preferred algorithm when GPUs or FPGA/ASIC cracking are in your threat model (which they should be).
                  – Polynomial
                  Nov 19 at 15:33






                • 6




                  +1. Note that this actually depends on how long your user base is willing to wait for auth (and how much load your auth systems can take in parallel). At the sub-100ms mark, bcrypt is actually more resistant to bruteforce. Only above ~1s/auth does Argon2 become superior. Refs: twitter.com/Sc00bzT/status/1063895918246862848, twitter.com/Sc00bzT/status/1041875128311840768
                  – Royce Williams
                  Nov 19 at 15:37







                • 1




                  Is it really? You tell me you securely store my data, I give you sensitive data to store, you then lose the data because it's not actually secure, wouldn't it be better to be up front and state you're not securely storing the data in the first place? ...idealistically speaking
                  – RandomUs1r
                  Nov 19 at 22:16






                • 3




                  @RandomUs1r What do you mean "not securely storing the data"? PBKDF2, while a bit old, is still considered secure if you use 10,000 iterations of SHA-1 or SHA-2 and unique per-user salts. If you have a SHA-2 primitive available, then you can build PBKDF2 (or something which is functionally equivalent). Please back up your statement that this is only an illusion of security.
                  – Mike Ounsworth
                  Nov 20 at 13:05







                • 4




                  @JFB I think so, but I wouldn't give it to the new hire. Looking at the PBKDF2 spec or an open-source implementation and applying a medium amount of attention to detail would do the trick. Put another way: I would trust myself to implement something PBKDF2-like in a day or two and use it in prod. I would under no circumstances trust myself to implement SHA-2 in under a month.
                  – Mike Ounsworth
                  2 days ago







                7




                7




                I'd suggest including Argon2 in your list, since it's currently the preferred algorithm when GPUs or FPGA/ASIC cracking are in your threat model (which they should be).
                – Polynomial
                Nov 19 at 15:33




                I'd suggest including Argon2 in your list, since it's currently the preferred algorithm when GPUs or FPGA/ASIC cracking are in your threat model (which they should be).
                – Polynomial
                Nov 19 at 15:33




                6




                6




                +1. Note that this actually depends on how long your user base is willing to wait for auth (and how much load your auth systems can take in parallel). At the sub-100ms mark, bcrypt is actually more resistant to bruteforce. Only above ~1s/auth does Argon2 become superior. Refs: twitter.com/Sc00bzT/status/1063895918246862848, twitter.com/Sc00bzT/status/1041875128311840768
                – Royce Williams
                Nov 19 at 15:37





                +1. Note that this actually depends on how long your user base is willing to wait for auth (and how much load your auth systems can take in parallel). At the sub-100ms mark, bcrypt is actually more resistant to bruteforce. Only above ~1s/auth does Argon2 become superior. Refs: twitter.com/Sc00bzT/status/1063895918246862848, twitter.com/Sc00bzT/status/1041875128311840768
                – Royce Williams
                Nov 19 at 15:37





                1




                1




                Is it really? You tell me you securely store my data, I give you sensitive data to store, you then lose the data because it's not actually secure, wouldn't it be better to be up front and state you're not securely storing the data in the first place? ...idealistically speaking
                – RandomUs1r
                Nov 19 at 22:16




                Is it really? You tell me you securely store my data, I give you sensitive data to store, you then lose the data because it's not actually secure, wouldn't it be better to be up front and state you're not securely storing the data in the first place? ...idealistically speaking
                – RandomUs1r
                Nov 19 at 22:16




                3




                3




                @RandomUs1r What do you mean "not securely storing the data"? PBKDF2, while a bit old, is still considered secure if you use 10,000 iterations of SHA-1 or SHA-2 and unique per-user salts. If you have a SHA-2 primitive available, then you can build PBKDF2 (or something which is functionally equivalent). Please back up your statement that this is only an illusion of security.
                – Mike Ounsworth
                Nov 20 at 13:05





                @RandomUs1r What do you mean "not securely storing the data"? PBKDF2, while a bit old, is still considered secure if you use 10,000 iterations of SHA-1 or SHA-2 and unique per-user salts. If you have a SHA-2 primitive available, then you can build PBKDF2 (or something which is functionally equivalent). Please back up your statement that this is only an illusion of security.
                – Mike Ounsworth
                Nov 20 at 13:05





                4




                4




                @JFB I think so, but I wouldn't give it to the new hire. Looking at the PBKDF2 spec or an open-source implementation and applying a medium amount of attention to detail would do the trick. Put another way: I would trust myself to implement something PBKDF2-like in a day or two and use it in prod. I would under no circumstances trust myself to implement SHA-2 in under a month.
                – Mike Ounsworth
                2 days ago




                @JFB I think so, but I wouldn't give it to the new hire. Looking at the PBKDF2 spec or an open-source implementation and applying a medium amount of attention to detail would do the trick. Put another way: I would trust myself to implement something PBKDF2-like in a day or two and use it in prod. I would under no circumstances trust myself to implement SHA-2 in under a month.
                – Mike Ounsworth
                2 days ago










                up vote
                27
                down vote













                As others have said, try to find a strong standalone implementation in your platform's language if at all possible.



                But if you can't use a strong hash ... then you should definitely still hash your users' passwords, even with a weak hash - because even a weak hash will protect a strong password.



                When tools like hashcat can guess billions of passwords per second, weak hashes won't protect weak passwords. But if one of your security-conscious users selects an uncrackable password like 'SDXBZsRVBKVnXznpLTBMIKhTX' or 'afferently-imitatee-snowmelt-heirdom-leeching' ... then even a weak hash like SHA1 will still put that password out of reach of a bruteforce attack.



                By using even a weak hash, you can at least enable your savvy users to protect themselves even though your system is weak. (And if you have the ability to stretch - to use the same algorithm thousands of times in a row - this will slow down the attacker as well).



                But your savvy users won't be reusing passwords, so even this is of limited value (except for "semi-savvy" users who have picked passwords strong enough to resist bruteforce, but may be reusing that password elsewhere or using a human-parseable password selection scheme ... so using even a weak hash will protect these users as well).



                Your best option for all users is to find a way to use a strong hash.



                [Edit: the OP has updated the question to indicate that they are the only user of the system, and can set an arbitrarily random password (which seems pretty odd to me; I don't know of a system with such a strange combination of "I am the only user", "I can only pick from a few hashing algorithms", and "All of the hashing algorithms are weak"). Either way, this makes my concern about protecting general users' weak passwords irrelevant for this specific question. Other answers should clarify at the beginning of their answers that they are giving advice that would normally be pretty bad, and is only applicable to this very specific question.]






                share|improve this answer






















                • I updated my question with additional information adressing your point of being able to at least protect strong, unique passwords
                  – JFB
                  Nov 19 at 16:03






                • 2




                  Password reuse is when users choose to use the same password across multiple sites (Facebook, their bank, etc.) ... not when two users are using the same password on the same site.
                  – Royce Williams
                  Nov 19 at 16:15










                • I agree, but with the added caveat that you should NOT use SHA-1 to produce a digest of any sensitive data (like passwords) without using random salt to address password re-use, plus key stretching.
                  – Craig
                  Nov 19 at 22:54






                • 8




                  Upvote for even a weak hash will protect a strong password
                  – Kevin Voorn
                  Nov 20 at 10:04














                up vote
                27
                down vote













                As others have said, try to find a strong standalone implementation in your platform's language if at all possible.



                But if you can't use a strong hash ... then you should definitely still hash your users' passwords, even with a weak hash - because even a weak hash will protect a strong password.



                When tools like hashcat can guess billions of passwords per second, weak hashes won't protect weak passwords. But if one of your security-conscious users selects an uncrackable password like 'SDXBZsRVBKVnXznpLTBMIKhTX' or 'afferently-imitatee-snowmelt-heirdom-leeching' ... then even a weak hash like SHA1 will still put that password out of reach of a bruteforce attack.



                By using even a weak hash, you can at least enable your savvy users to protect themselves even though your system is weak. (And if you have the ability to stretch - to use the same algorithm thousands of times in a row - this will slow down the attacker as well).



                But your savvy users won't be reusing passwords, so even this is of limited value (except for "semi-savvy" users who have picked passwords strong enough to resist bruteforce, but may be reusing that password elsewhere or using a human-parseable password selection scheme ... so using even a weak hash will protect these users as well).



                Your best option for all users is to find a way to use a strong hash.



                [Edit: the OP has updated the question to indicate that they are the only user of the system, and can set an arbitrarily random password (which seems pretty odd to me; I don't know of a system with such a strange combination of "I am the only user", "I can only pick from a few hashing algorithms", and "All of the hashing algorithms are weak"). Either way, this makes my concern about protecting general users' weak passwords irrelevant for this specific question. Other answers should clarify at the beginning of their answers that they are giving advice that would normally be pretty bad, and is only applicable to this very specific question.]






                share|improve this answer






















                • I updated my question with additional information adressing your point of being able to at least protect strong, unique passwords
                  – JFB
                  Nov 19 at 16:03






                • 2




                  Password reuse is when users choose to use the same password across multiple sites (Facebook, their bank, etc.) ... not when two users are using the same password on the same site.
                  – Royce Williams
                  Nov 19 at 16:15










                • I agree, but with the added caveat that you should NOT use SHA-1 to produce a digest of any sensitive data (like passwords) without using random salt to address password re-use, plus key stretching.
                  – Craig
                  Nov 19 at 22:54






                • 8




                  Upvote for even a weak hash will protect a strong password
                  – Kevin Voorn
                  Nov 20 at 10:04












                up vote
                27
                down vote










                up vote
                27
                down vote









                As others have said, try to find a strong standalone implementation in your platform's language if at all possible.



                But if you can't use a strong hash ... then you should definitely still hash your users' passwords, even with a weak hash - because even a weak hash will protect a strong password.



                When tools like hashcat can guess billions of passwords per second, weak hashes won't protect weak passwords. But if one of your security-conscious users selects an uncrackable password like 'SDXBZsRVBKVnXznpLTBMIKhTX' or 'afferently-imitatee-snowmelt-heirdom-leeching' ... then even a weak hash like SHA1 will still put that password out of reach of a bruteforce attack.



                By using even a weak hash, you can at least enable your savvy users to protect themselves even though your system is weak. (And if you have the ability to stretch - to use the same algorithm thousands of times in a row - this will slow down the attacker as well).



                But your savvy users won't be reusing passwords, so even this is of limited value (except for "semi-savvy" users who have picked passwords strong enough to resist bruteforce, but may be reusing that password elsewhere or using a human-parseable password selection scheme ... so using even a weak hash will protect these users as well).



                Your best option for all users is to find a way to use a strong hash.



                [Edit: the OP has updated the question to indicate that they are the only user of the system, and can set an arbitrarily random password (which seems pretty odd to me; I don't know of a system with such a strange combination of "I am the only user", "I can only pick from a few hashing algorithms", and "All of the hashing algorithms are weak"). Either way, this makes my concern about protecting general users' weak passwords irrelevant for this specific question. Other answers should clarify at the beginning of their answers that they are giving advice that would normally be pretty bad, and is only applicable to this very specific question.]






                share|improve this answer














                As others have said, try to find a strong standalone implementation in your platform's language if at all possible.



                But if you can't use a strong hash ... then you should definitely still hash your users' passwords, even with a weak hash - because even a weak hash will protect a strong password.



                When tools like hashcat can guess billions of passwords per second, weak hashes won't protect weak passwords. But if one of your security-conscious users selects an uncrackable password like 'SDXBZsRVBKVnXznpLTBMIKhTX' or 'afferently-imitatee-snowmelt-heirdom-leeching' ... then even a weak hash like SHA1 will still put that password out of reach of a bruteforce attack.



                By using even a weak hash, you can at least enable your savvy users to protect themselves even though your system is weak. (And if you have the ability to stretch - to use the same algorithm thousands of times in a row - this will slow down the attacker as well).



                But your savvy users won't be reusing passwords, so even this is of limited value (except for "semi-savvy" users who have picked passwords strong enough to resist bruteforce, but may be reusing that password elsewhere or using a human-parseable password selection scheme ... so using even a weak hash will protect these users as well).



                Your best option for all users is to find a way to use a strong hash.



                [Edit: the OP has updated the question to indicate that they are the only user of the system, and can set an arbitrarily random password (which seems pretty odd to me; I don't know of a system with such a strange combination of "I am the only user", "I can only pick from a few hashing algorithms", and "All of the hashing algorithms are weak"). Either way, this makes my concern about protecting general users' weak passwords irrelevant for this specific question. Other answers should clarify at the beginning of their answers that they are giving advice that would normally be pretty bad, and is only applicable to this very specific question.]







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited 7 hours ago

























                answered Nov 19 at 15:45









                Royce Williams

                5,04211540




                5,04211540











                • I updated my question with additional information adressing your point of being able to at least protect strong, unique passwords
                  – JFB
                  Nov 19 at 16:03






                • 2




                  Password reuse is when users choose to use the same password across multiple sites (Facebook, their bank, etc.) ... not when two users are using the same password on the same site.
                  – Royce Williams
                  Nov 19 at 16:15










                • I agree, but with the added caveat that you should NOT use SHA-1 to produce a digest of any sensitive data (like passwords) without using random salt to address password re-use, plus key stretching.
                  – Craig
                  Nov 19 at 22:54






                • 8




                  Upvote for even a weak hash will protect a strong password
                  – Kevin Voorn
                  Nov 20 at 10:04
















                • I updated my question with additional information adressing your point of being able to at least protect strong, unique passwords
                  – JFB
                  Nov 19 at 16:03






                • 2




                  Password reuse is when users choose to use the same password across multiple sites (Facebook, their bank, etc.) ... not when two users are using the same password on the same site.
                  – Royce Williams
                  Nov 19 at 16:15










                • I agree, but with the added caveat that you should NOT use SHA-1 to produce a digest of any sensitive data (like passwords) without using random salt to address password re-use, plus key stretching.
                  – Craig
                  Nov 19 at 22:54






                • 8




                  Upvote for even a weak hash will protect a strong password
                  – Kevin Voorn
                  Nov 20 at 10:04















                I updated my question with additional information adressing your point of being able to at least protect strong, unique passwords
                – JFB
                Nov 19 at 16:03




                I updated my question with additional information adressing your point of being able to at least protect strong, unique passwords
                – JFB
                Nov 19 at 16:03




                2




                2




                Password reuse is when users choose to use the same password across multiple sites (Facebook, their bank, etc.) ... not when two users are using the same password on the same site.
                – Royce Williams
                Nov 19 at 16:15




                Password reuse is when users choose to use the same password across multiple sites (Facebook, their bank, etc.) ... not when two users are using the same password on the same site.
                – Royce Williams
                Nov 19 at 16:15












                I agree, but with the added caveat that you should NOT use SHA-1 to produce a digest of any sensitive data (like passwords) without using random salt to address password re-use, plus key stretching.
                – Craig
                Nov 19 at 22:54




                I agree, but with the added caveat that you should NOT use SHA-1 to produce a digest of any sensitive data (like passwords) without using random salt to address password re-use, plus key stretching.
                – Craig
                Nov 19 at 22:54




                8




                8




                Upvote for even a weak hash will protect a strong password
                – Kevin Voorn
                Nov 20 at 10:04




                Upvote for even a weak hash will protect a strong password
                – Kevin Voorn
                Nov 20 at 10:04










                up vote
                16
                down vote













                SHA-2 in this particular case is just as secure as PBKDF/scrypt/bcrypt. Iterations are unnecessary and wasteful. Generate high-entropy (256 bit) passwords and forget about KDFs and even salts.



                In fact, it makes more sense to use SHA-2 than PBKDF because there is no existing platform implementation of the algorithm and "rolling your own crypto" is a no-no.



                That's quite a strong statement. The essence here in the question is that the OP has full control of the passwords he stores on the system and knows that he will be the only one storing passwords on the system.



                Signal makes use of a construction called HKDF in its double-ratchet algorithm, which essentially applies the hashing algorithm for only one iteration.



                Why is this okay?



                Password KDFs exist for precisely one reason: low-entropy passwords. Most people won't remember a 128- or 256-bit key generated from a CSRNG in their heads. I'd venture that most people can remember at most a 40-bit random string for a long enough period of time to use it.



                Pretty much all hash functions (even MD4, MD5, and SHA-1, but since you said you have SHA-2 on the platform, let's be safe here) have a feature called preimage resistance, which is good enough for your application since you control all of the passwords that get stored on your system. This means that it is computationally infeasible, given a hash, to generate something that hashes to the same hash.



                Simplifying a bit, the most practical way to generate a preimage for one of these hash functions is to keep trying inputs. There are a few examples of attacks that do slightly better than brute force, but they're totally infeasible. Now, if the password/key you chose to put into the hash function only has 16 bits of entropy, this resistance property won't do you much, because the attacker will be able to try all 65536 different inputs you could have put in.



                Why control of the password matters



                Think less of the things that you're putting in as "passwords" but more as cryptographic keys. As long as you are hashing keys that have entropy greater than or equal to the number of bits output by your choice of hash function (for SHA-256, that's 256 bits), then you're totally fine just running one iteration of the hash over it to prevent key extraction. The preimage resistance of the hash combined with the high entropy of your key means that an attacker simply cannot guess the value that you put in. There's no need for the thousands of iterations or arguing with the business side or reasoning about an abstract attack to not-so-receptive bosses. FPGA/ASIC resistance is a moot point when you have to guess a 256-bit input into the hash function.



                Recommendations



                Generate your "passwords" with a hardware RNG or a CSPRNG and promptly destroy any seed material that could be used to recover any internal state and therefore the passwords. Make sure that these are 256 bits long. If your system doesn't support non-alphanumeric or non-ASCII passwords, then after you generate the 256 bits, encode it in base-64 or base-26 or binary if you like. (This means that the actual passwords that you submit will be longer than 32 bytes, but this doesn't help entropy much.)



                Treat these passwords like cryptographic keys -- ideally, they would be stored on hardware tokens. A hardware password manager works very well for this purpose. Store the SHA-256 hashes in your system, and verify the passwords by hashing and comparing. You should reject all attempted passwords that do not match your generation criterion (an example would be a user-selected password < 256 bits), even if the hashes match, and you should not allow anyone to set a password that did not come from a CSRNG. This should be
                documented. Even better is if you add some obscure checksum byte at the end of the passwords that you generate that is verified by the platform before it allows you to set the password. This should deter all but the most hilariously incompetent people from putting anything less than a cryptographic key on your platform.



                Public Key Cryptography



                Your use case is a bit odd. Most places maintain passwords because setting up a PKI and dealing with end-users is very difficult, especially with things like public keys. Since you seem to be the only one entering passwords into the system, maybe it would make more sense to store Ed25519 or ECDSA public keys on the system and write code there that implements a challenge-response protocol (a simple one is sign this 256-bit value -- but be careful that you don't reuse these keys, as someone might trick you into signing away your Bitcoin or a criminal confession). The device that would interface with your system here and maintain the private keys probably has a strong implementation of public-key cryptography and would have no problem authenticating itself. Your "roll my own" implementation of the signature verification could be the least secure in the world in terms of side-channel attacks (think of putting its entire state on a billboard or the blockchain), as long as it gives the correct answer, and you would be perfectly fine, as the verification algorithm simply has no access to the private keys.






                share|improve this answer










                New contributor




                John Adams is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.













                • 2




                  I ... um ... Most of this answer appears to be about completely unrelated cryptography topics and/or highly misguided. The remainder is disconnected from how password-storage techniques actually work. Salting and iterations are 100% how passwords are securely stored. Further, recommending that someone use straight SHA-2 is very bad advice; my 6x 1080 rig can guess 18.7 billion passwords per second of SHA-2, but only 95,000 per second of bcrypt cost 5 (and bcrypt cost 12 or higher is the current modern target)
                  – Royce Williams
                  Nov 20 at 5:48







                • 8




                  @RoyceWilliams I'm not a security professional, but if I understand OP correctly, they're advocating that users put in no less then 256 bits of entropy for passwords. Even at your 18.7 billion attempts a second, if my back of the napkin math is correct ((2^256) / 18.700.000.000 / 60 / 60 / 24 / 365) then you'd still need 1.963*e+59 years to try all combinations, which I think would qualify as "computationally infeasible" even if you assume that highly optimized hardware would be 100.000 times more efficient.
                  – Magisch
                  Nov 20 at 12:20






                • 2




                  In other words, to a non security professional like me, it would seem that the answerer is correct in that every preimage resistant hashing algorhitm could be considered safe if you can guarantee non reused 256 bit entropy passwords.
                  – Magisch
                  Nov 20 at 12:29






                • 1




                  To put it simply, very long, securely generated passwords are essentially what cryptographic keys are.
                  – John Adams
                  Nov 20 at 22:10






                • 6




                  @RoyceWilliams You seem to misunderstand the gist of the answer. If your passwords have enough entropy, then a KDF is unnecessary. KDFs are used because most passwords are low-entropy. When your passwords get to entropy levels comparable to those of cryptographic keys, it really doesn't matter how they're hashed, as long as the hash has preimage resistance.
                  – John Adams
                  Nov 20 at 22:15














                up vote
                16
                down vote













                SHA-2 in this particular case is just as secure as PBKDF/scrypt/bcrypt. Iterations are unnecessary and wasteful. Generate high-entropy (256 bit) passwords and forget about KDFs and even salts.



                In fact, it makes more sense to use SHA-2 than PBKDF because there is no existing platform implementation of the algorithm and "rolling your own crypto" is a no-no.



                That's quite a strong statement. The essence here in the question is that the OP has full control of the passwords he stores on the system and knows that he will be the only one storing passwords on the system.



                Signal makes use of a construction called HKDF in its double-ratchet algorithm, which essentially applies the hashing algorithm for only one iteration.



                Why is this okay?



                Password KDFs exist for precisely one reason: low-entropy passwords. Most people won't remember a 128- or 256-bit key generated from a CSRNG in their heads. I'd venture that most people can remember at most a 40-bit random string for a long enough period of time to use it.



                Pretty much all hash functions (even MD4, MD5, and SHA-1, but since you said you have SHA-2 on the platform, let's be safe here) have a feature called preimage resistance, which is good enough for your application since you control all of the passwords that get stored on your system. This means that it is computationally infeasible, given a hash, to generate something that hashes to the same hash.



                Simplifying a bit, the most practical way to generate a preimage for one of these hash functions is to keep trying inputs. There are a few examples of attacks that do slightly better than brute force, but they're totally infeasible. Now, if the password/key you chose to put into the hash function only has 16 bits of entropy, this resistance property won't do you much, because the attacker will be able to try all 65536 different inputs you could have put in.



                Why control of the password matters



                Think less of the things that you're putting in as "passwords" but more as cryptographic keys. As long as you are hashing keys that have entropy greater than or equal to the number of bits output by your choice of hash function (for SHA-256, that's 256 bits), then you're totally fine just running one iteration of the hash over it to prevent key extraction. The preimage resistance of the hash combined with the high entropy of your key means that an attacker simply cannot guess the value that you put in. There's no need for the thousands of iterations or arguing with the business side or reasoning about an abstract attack to not-so-receptive bosses. FPGA/ASIC resistance is a moot point when you have to guess a 256-bit input into the hash function.



                Recommendations



                Generate your "passwords" with a hardware RNG or a CSPRNG and promptly destroy any seed material that could be used to recover any internal state and therefore the passwords. Make sure that these are 256 bits long. If your system doesn't support non-alphanumeric or non-ASCII passwords, then after you generate the 256 bits, encode it in base-64 or base-26 or binary if you like. (This means that the actual passwords that you submit will be longer than 32 bytes, but this doesn't help entropy much.)



                Treat these passwords like cryptographic keys -- ideally, they would be stored on hardware tokens. A hardware password manager works very well for this purpose. Store the SHA-256 hashes in your system, and verify the passwords by hashing and comparing. You should reject all attempted passwords that do not match your generation criterion (an example would be a user-selected password < 256 bits), even if the hashes match, and you should not allow anyone to set a password that did not come from a CSRNG. This should be
                documented. Even better is if you add some obscure checksum byte at the end of the passwords that you generate that is verified by the platform before it allows you to set the password. This should deter all but the most hilariously incompetent people from putting anything less than a cryptographic key on your platform.



                Public Key Cryptography



                Your use case is a bit odd. Most places maintain passwords because setting up a PKI and dealing with end-users is very difficult, especially with things like public keys. Since you seem to be the only one entering passwords into the system, maybe it would make more sense to store Ed25519 or ECDSA public keys on the system and write code there that implements a challenge-response protocol (a simple one is sign this 256-bit value -- but be careful that you don't reuse these keys, as someone might trick you into signing away your Bitcoin or a criminal confession). The device that would interface with your system here and maintain the private keys probably has a strong implementation of public-key cryptography and would have no problem authenticating itself. Your "roll my own" implementation of the signature verification could be the least secure in the world in terms of side-channel attacks (think of putting its entire state on a billboard or the blockchain), as long as it gives the correct answer, and you would be perfectly fine, as the verification algorithm simply has no access to the private keys.






                share|improve this answer










                New contributor




                John Adams is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.













                • 2




                  I ... um ... Most of this answer appears to be about completely unrelated cryptography topics and/or highly misguided. The remainder is disconnected from how password-storage techniques actually work. Salting and iterations are 100% how passwords are securely stored. Further, recommending that someone use straight SHA-2 is very bad advice; my 6x 1080 rig can guess 18.7 billion passwords per second of SHA-2, but only 95,000 per second of bcrypt cost 5 (and bcrypt cost 12 or higher is the current modern target)
                  – Royce Williams
                  Nov 20 at 5:48







                • 8




                  @RoyceWilliams I'm not a security professional, but if I understand OP correctly, they're advocating that users put in no less then 256 bits of entropy for passwords. Even at your 18.7 billion attempts a second, if my back of the napkin math is correct ((2^256) / 18.700.000.000 / 60 / 60 / 24 / 365) then you'd still need 1.963*e+59 years to try all combinations, which I think would qualify as "computationally infeasible" even if you assume that highly optimized hardware would be 100.000 times more efficient.
                  – Magisch
                  Nov 20 at 12:20






                • 2




                  In other words, to a non security professional like me, it would seem that the answerer is correct in that every preimage resistant hashing algorhitm could be considered safe if you can guarantee non reused 256 bit entropy passwords.
                  – Magisch
                  Nov 20 at 12:29






                • 1




                  To put it simply, very long, securely generated passwords are essentially what cryptographic keys are.
                  – John Adams
                  Nov 20 at 22:10






                • 6




                  @RoyceWilliams You seem to misunderstand the gist of the answer. If your passwords have enough entropy, then a KDF is unnecessary. KDFs are used because most passwords are low-entropy. When your passwords get to entropy levels comparable to those of cryptographic keys, it really doesn't matter how they're hashed, as long as the hash has preimage resistance.
                  – John Adams
                  Nov 20 at 22:15












                up vote
                16
                down vote










                up vote
                16
                down vote









                SHA-2 in this particular case is just as secure as PBKDF/scrypt/bcrypt. Iterations are unnecessary and wasteful. Generate high-entropy (256 bit) passwords and forget about KDFs and even salts.



                In fact, it makes more sense to use SHA-2 than PBKDF because there is no existing platform implementation of the algorithm and "rolling your own crypto" is a no-no.



                That's quite a strong statement. The essence here in the question is that the OP has full control of the passwords he stores on the system and knows that he will be the only one storing passwords on the system.



                Signal makes use of a construction called HKDF in its double-ratchet algorithm, which essentially applies the hashing algorithm for only one iteration.



                Why is this okay?



                Password KDFs exist for precisely one reason: low-entropy passwords. Most people won't remember a 128- or 256-bit key generated from a CSRNG in their heads. I'd venture that most people can remember at most a 40-bit random string for a long enough period of time to use it.



                Pretty much all hash functions (even MD4, MD5, and SHA-1, but since you said you have SHA-2 on the platform, let's be safe here) have a feature called preimage resistance, which is good enough for your application since you control all of the passwords that get stored on your system. This means that it is computationally infeasible, given a hash, to generate something that hashes to the same hash.



                Simplifying a bit, the most practical way to generate a preimage for one of these hash functions is to keep trying inputs. There are a few examples of attacks that do slightly better than brute force, but they're totally infeasible. Now, if the password/key you chose to put into the hash function only has 16 bits of entropy, this resistance property won't do you much, because the attacker will be able to try all 65536 different inputs you could have put in.



                Why control of the password matters



                Think less of the things that you're putting in as "passwords" but more as cryptographic keys. As long as you are hashing keys that have entropy greater than or equal to the number of bits output by your choice of hash function (for SHA-256, that's 256 bits), then you're totally fine just running one iteration of the hash over it to prevent key extraction. The preimage resistance of the hash combined with the high entropy of your key means that an attacker simply cannot guess the value that you put in. There's no need for the thousands of iterations or arguing with the business side or reasoning about an abstract attack to not-so-receptive bosses. FPGA/ASIC resistance is a moot point when you have to guess a 256-bit input into the hash function.



                Recommendations



                Generate your "passwords" with a hardware RNG or a CSPRNG and promptly destroy any seed material that could be used to recover any internal state and therefore the passwords. Make sure that these are 256 bits long. If your system doesn't support non-alphanumeric or non-ASCII passwords, then after you generate the 256 bits, encode it in base-64 or base-26 or binary if you like. (This means that the actual passwords that you submit will be longer than 32 bytes, but this doesn't help entropy much.)



                Treat these passwords like cryptographic keys -- ideally, they would be stored on hardware tokens. A hardware password manager works very well for this purpose. Store the SHA-256 hashes in your system, and verify the passwords by hashing and comparing. You should reject all attempted passwords that do not match your generation criterion (an example would be a user-selected password < 256 bits), even if the hashes match, and you should not allow anyone to set a password that did not come from a CSRNG. This should be
                documented. Even better is if you add some obscure checksum byte at the end of the passwords that you generate that is verified by the platform before it allows you to set the password. This should deter all but the most hilariously incompetent people from putting anything less than a cryptographic key on your platform.



                Public Key Cryptography



                Your use case is a bit odd. Most places maintain passwords because setting up a PKI and dealing with end-users is very difficult, especially with things like public keys. Since you seem to be the only one entering passwords into the system, maybe it would make more sense to store Ed25519 or ECDSA public keys on the system and write code there that implements a challenge-response protocol (a simple one is sign this 256-bit value -- but be careful that you don't reuse these keys, as someone might trick you into signing away your Bitcoin or a criminal confession). The device that would interface with your system here and maintain the private keys probably has a strong implementation of public-key cryptography and would have no problem authenticating itself. Your "roll my own" implementation of the signature verification could be the least secure in the world in terms of side-channel attacks (think of putting its entire state on a billboard or the blockchain), as long as it gives the correct answer, and you would be perfectly fine, as the verification algorithm simply has no access to the private keys.






                share|improve this answer










                New contributor




                John Adams is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.









                SHA-2 in this particular case is just as secure as PBKDF/scrypt/bcrypt. Iterations are unnecessary and wasteful. Generate high-entropy (256 bit) passwords and forget about KDFs and even salts.



                In fact, it makes more sense to use SHA-2 than PBKDF because there is no existing platform implementation of the algorithm and "rolling your own crypto" is a no-no.



                That's quite a strong statement. The essence here in the question is that the OP has full control of the passwords he stores on the system and knows that he will be the only one storing passwords on the system.



                Signal makes use of a construction called HKDF in its double-ratchet algorithm, which essentially applies the hashing algorithm for only one iteration.



                Why is this okay?



                Password KDFs exist for precisely one reason: low-entropy passwords. Most people won't remember a 128- or 256-bit key generated from a CSRNG in their heads. I'd venture that most people can remember at most a 40-bit random string for a long enough period of time to use it.



                Pretty much all hash functions (even MD4, MD5, and SHA-1, but since you said you have SHA-2 on the platform, let's be safe here) have a feature called preimage resistance, which is good enough for your application since you control all of the passwords that get stored on your system. This means that it is computationally infeasible, given a hash, to generate something that hashes to the same hash.



                Simplifying a bit, the most practical way to generate a preimage for one of these hash functions is to keep trying inputs. There are a few examples of attacks that do slightly better than brute force, but they're totally infeasible. Now, if the password/key you chose to put into the hash function only has 16 bits of entropy, this resistance property won't do you much, because the attacker will be able to try all 65536 different inputs you could have put in.



                Why control of the password matters



                Think less of the things that you're putting in as "passwords" but more as cryptographic keys. As long as you are hashing keys that have entropy greater than or equal to the number of bits output by your choice of hash function (for SHA-256, that's 256 bits), then you're totally fine just running one iteration of the hash over it to prevent key extraction. The preimage resistance of the hash combined with the high entropy of your key means that an attacker simply cannot guess the value that you put in. There's no need for the thousands of iterations or arguing with the business side or reasoning about an abstract attack to not-so-receptive bosses. FPGA/ASIC resistance is a moot point when you have to guess a 256-bit input into the hash function.



                Recommendations



                Generate your "passwords" with a hardware RNG or a CSPRNG and promptly destroy any seed material that could be used to recover any internal state and therefore the passwords. Make sure that these are 256 bits long. If your system doesn't support non-alphanumeric or non-ASCII passwords, then after you generate the 256 bits, encode it in base-64 or base-26 or binary if you like. (This means that the actual passwords that you submit will be longer than 32 bytes, but this doesn't help entropy much.)



                Treat these passwords like cryptographic keys -- ideally, they would be stored on hardware tokens. A hardware password manager works very well for this purpose. Store the SHA-256 hashes in your system, and verify the passwords by hashing and comparing. You should reject all attempted passwords that do not match your generation criterion (an example would be a user-selected password < 256 bits), even if the hashes match, and you should not allow anyone to set a password that did not come from a CSRNG. This should be
                documented. Even better is if you add some obscure checksum byte at the end of the passwords that you generate that is verified by the platform before it allows you to set the password. This should deter all but the most hilariously incompetent people from putting anything less than a cryptographic key on your platform.



                Public Key Cryptography



                Your use case is a bit odd. Most places maintain passwords because setting up a PKI and dealing with end-users is very difficult, especially with things like public keys. Since you seem to be the only one entering passwords into the system, maybe it would make more sense to store Ed25519 or ECDSA public keys on the system and write code there that implements a challenge-response protocol (a simple one is sign this 256-bit value -- but be careful that you don't reuse these keys, as someone might trick you into signing away your Bitcoin or a criminal confession). The device that would interface with your system here and maintain the private keys probably has a strong implementation of public-key cryptography and would have no problem authenticating itself. Your "roll my own" implementation of the signature verification could be the least secure in the world in terms of side-channel attacks (think of putting its entire state on a billboard or the blockchain), as long as it gives the correct answer, and you would be perfectly fine, as the verification algorithm simply has no access to the private keys.







                share|improve this answer










                New contributor




                John Adams is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.









                share|improve this answer



                share|improve this answer








                edited Nov 20 at 4:41





















                New contributor




                John Adams is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.









                answered Nov 20 at 4:27









                John Adams

                1773




                1773




                New contributor




                John Adams is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.





                New contributor





                John Adams is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.






                John Adams is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.







                • 2




                  I ... um ... Most of this answer appears to be about completely unrelated cryptography topics and/or highly misguided. The remainder is disconnected from how password-storage techniques actually work. Salting and iterations are 100% how passwords are securely stored. Further, recommending that someone use straight SHA-2 is very bad advice; my 6x 1080 rig can guess 18.7 billion passwords per second of SHA-2, but only 95,000 per second of bcrypt cost 5 (and bcrypt cost 12 or higher is the current modern target)
                  – Royce Williams
                  Nov 20 at 5:48







                • 8




                  @RoyceWilliams I'm not a security professional, but if I understand OP correctly, they're advocating that users put in no less then 256 bits of entropy for passwords. Even at your 18.7 billion attempts a second, if my back of the napkin math is correct ((2^256) / 18.700.000.000 / 60 / 60 / 24 / 365) then you'd still need 1.963*e+59 years to try all combinations, which I think would qualify as "computationally infeasible" even if you assume that highly optimized hardware would be 100.000 times more efficient.
                  – Magisch
                  Nov 20 at 12:20






                • 2




                  In other words, to a non security professional like me, it would seem that the answerer is correct in that every preimage resistant hashing algorhitm could be considered safe if you can guarantee non reused 256 bit entropy passwords.
                  – Magisch
                  Nov 20 at 12:29






                • 1




                  To put it simply, very long, securely generated passwords are essentially what cryptographic keys are.
                  – John Adams
                  Nov 20 at 22:10






                • 6




                  @RoyceWilliams You seem to misunderstand the gist of the answer. If your passwords have enough entropy, then a KDF is unnecessary. KDFs are used because most passwords are low-entropy. When your passwords get to entropy levels comparable to those of cryptographic keys, it really doesn't matter how they're hashed, as long as the hash has preimage resistance.
                  – John Adams
                  Nov 20 at 22:15












                • 2




                  I ... um ... Most of this answer appears to be about completely unrelated cryptography topics and/or highly misguided. The remainder is disconnected from how password-storage techniques actually work. Salting and iterations are 100% how passwords are securely stored. Further, recommending that someone use straight SHA-2 is very bad advice; my 6x 1080 rig can guess 18.7 billion passwords per second of SHA-2, but only 95,000 per second of bcrypt cost 5 (and bcrypt cost 12 or higher is the current modern target)
                  – Royce Williams
                  Nov 20 at 5:48







                • 8




                  @RoyceWilliams I'm not a security professional, but if I understand OP correctly, they're advocating that users put in no less then 256 bits of entropy for passwords. Even at your 18.7 billion attempts a second, if my back of the napkin math is correct ((2^256) / 18.700.000.000 / 60 / 60 / 24 / 365) then you'd still need 1.963*e+59 years to try all combinations, which I think would qualify as "computationally infeasible" even if you assume that highly optimized hardware would be 100.000 times more efficient.
                  – Magisch
                  Nov 20 at 12:20






                • 2




                  In other words, to a non security professional like me, it would seem that the answerer is correct in that every preimage resistant hashing algorhitm could be considered safe if you can guarantee non reused 256 bit entropy passwords.
                  – Magisch
                  Nov 20 at 12:29






                • 1




                  To put it simply, very long, securely generated passwords are essentially what cryptographic keys are.
                  – John Adams
                  Nov 20 at 22:10






                • 6




                  @RoyceWilliams You seem to misunderstand the gist of the answer. If your passwords have enough entropy, then a KDF is unnecessary. KDFs are used because most passwords are low-entropy. When your passwords get to entropy levels comparable to those of cryptographic keys, it really doesn't matter how they're hashed, as long as the hash has preimage resistance.
                  – John Adams
                  Nov 20 at 22:15







                2




                2




                I ... um ... Most of this answer appears to be about completely unrelated cryptography topics and/or highly misguided. The remainder is disconnected from how password-storage techniques actually work. Salting and iterations are 100% how passwords are securely stored. Further, recommending that someone use straight SHA-2 is very bad advice; my 6x 1080 rig can guess 18.7 billion passwords per second of SHA-2, but only 95,000 per second of bcrypt cost 5 (and bcrypt cost 12 or higher is the current modern target)
                – Royce Williams
                Nov 20 at 5:48





                I ... um ... Most of this answer appears to be about completely unrelated cryptography topics and/or highly misguided. The remainder is disconnected from how password-storage techniques actually work. Salting and iterations are 100% how passwords are securely stored. Further, recommending that someone use straight SHA-2 is very bad advice; my 6x 1080 rig can guess 18.7 billion passwords per second of SHA-2, but only 95,000 per second of bcrypt cost 5 (and bcrypt cost 12 or higher is the current modern target)
                – Royce Williams
                Nov 20 at 5:48





                8




                8




                @RoyceWilliams I'm not a security professional, but if I understand OP correctly, they're advocating that users put in no less then 256 bits of entropy for passwords. Even at your 18.7 billion attempts a second, if my back of the napkin math is correct ((2^256) / 18.700.000.000 / 60 / 60 / 24 / 365) then you'd still need 1.963*e+59 years to try all combinations, which I think would qualify as "computationally infeasible" even if you assume that highly optimized hardware would be 100.000 times more efficient.
                – Magisch
                Nov 20 at 12:20




                @RoyceWilliams I'm not a security professional, but if I understand OP correctly, they're advocating that users put in no less then 256 bits of entropy for passwords. Even at your 18.7 billion attempts a second, if my back of the napkin math is correct ((2^256) / 18.700.000.000 / 60 / 60 / 24 / 365) then you'd still need 1.963*e+59 years to try all combinations, which I think would qualify as "computationally infeasible" even if you assume that highly optimized hardware would be 100.000 times more efficient.
                – Magisch
                Nov 20 at 12:20




                2




                2




                In other words, to a non security professional like me, it would seem that the answerer is correct in that every preimage resistant hashing algorhitm could be considered safe if you can guarantee non reused 256 bit entropy passwords.
                – Magisch
                Nov 20 at 12:29




                In other words, to a non security professional like me, it would seem that the answerer is correct in that every preimage resistant hashing algorhitm could be considered safe if you can guarantee non reused 256 bit entropy passwords.
                – Magisch
                Nov 20 at 12:29




                1




                1




                To put it simply, very long, securely generated passwords are essentially what cryptographic keys are.
                – John Adams
                Nov 20 at 22:10




                To put it simply, very long, securely generated passwords are essentially what cryptographic keys are.
                – John Adams
                Nov 20 at 22:10




                6




                6




                @RoyceWilliams You seem to misunderstand the gist of the answer. If your passwords have enough entropy, then a KDF is unnecessary. KDFs are used because most passwords are low-entropy. When your passwords get to entropy levels comparable to those of cryptographic keys, it really doesn't matter how they're hashed, as long as the hash has preimage resistance.
                – John Adams
                Nov 20 at 22:15




                @RoyceWilliams You seem to misunderstand the gist of the answer. If your passwords have enough entropy, then a KDF is unnecessary. KDFs are used because most passwords are low-entropy. When your passwords get to entropy levels comparable to those of cryptographic keys, it really doesn't matter how they're hashed, as long as the hash has preimage resistance.
                – John Adams
                Nov 20 at 22:15










                up vote
                3
                down vote













                I agree with Mike and Royce in their answers, and don't feel the need to repeat what they covered well. However I wanted to more directly address this comment of yours:




                Additional Information: I will be the only one storing passwords on
                that system, so I can 1) guarantee that none of the passwords will be
                used twice and 2) ensure that the passwords will have a very high
                entropy.




                This piece of information is both important and not-important. Here's why:



                The case for password hashing



                It's always important to remember why we hash passwords, and it all boils down to password reuse. The reason why password hashing is so important is because when your system gets compromised and passwords are stolen, it isn't just access to your site that is compromised, but access to every site where your users have re-used the same email/password combination which (as we know) happens a lot. Password hashing is about protecting users from themselves. If absolutely everyone used strong and unique passwords on every site, then password hashing would be a lot less necessary. It would still have some value because there are use cases where a hacker might gain read-only access to a database dump, so hashed passwords can provide some protection against attackers getting actual access to your system in. However, if people used strong and unique passwords everywhere then password hashing would become more of a secondary concern instead of the absolutely-critical necessity it is today.



                So, if you can guarantee that every user of your system will only ever use strong and unique passwords (i.e. passwords that have not been used on other sites), then I think that even something simple like SHA2 would actually be a perfectly reasonable choice, regardless of whether or not better functions were available.



                BUT: changing business needs



                However, I would encourage you to double check your assumptions (that strong unique passwords will be the only ones ever in your system). I've seen business needs change to often in the past to rely on assumptions like that in critical business areas (which this may not be - obviously I don't know what this does). The problem is that business needs change. Maybe it's just me, but in my experience things that were meant to be temporary or limited to just a couple people inevitably turn into critical business applications used by everyone in the company, and all of a sudden you have a weak password scheme protecting critical business infrastructure. It won't always happen because people are trying to cut corners, but because 12 months down the road you forget that you didn't use a great password hash, or you leave and then next guy doesn't look into it, or you're under pressure to meet a deadline and you forget, or, or, or...



                In my experience businesses end up having security breaches not because security is hard but because they don't understand the need for spending time (aka money) on good security practices and cut corners where they shouldn't. Sure, right now a great password hashing scheme doesn't matter, but can you really guarantee that that won't change in the future? If you don't have time to put in proper password hashing now, can you guarantee that when the needs change and it suddenly does matter, that you will have time to do it right then?



                Of course at the end of the day every business needs to make money, and sometimes "Let's keep this simple for now to get this out the door" is a perfectly reasonable answer. Just be careful though because making that decision too often is how companies end up with systems filled with security holes. As a company you have to find that balance for yourself. The trouble is that when companies chronically skimp on the security it is ultimately their customers that hurt the most.






                share|improve this answer




















                • +1 for "things that were meant to be temporary or limited to just a couple people inevitably turn into critical business applications"
                  – Kelly Bang
                  Nov 20 at 21:23














                up vote
                3
                down vote













                I agree with Mike and Royce in their answers, and don't feel the need to repeat what they covered well. However I wanted to more directly address this comment of yours:




                Additional Information: I will be the only one storing passwords on
                that system, so I can 1) guarantee that none of the passwords will be
                used twice and 2) ensure that the passwords will have a very high
                entropy.




                This piece of information is both important and not-important. Here's why:



                The case for password hashing



                It's always important to remember why we hash passwords, and it all boils down to password reuse. The reason why password hashing is so important is because when your system gets compromised and passwords are stolen, it isn't just access to your site that is compromised, but access to every site where your users have re-used the same email/password combination which (as we know) happens a lot. Password hashing is about protecting users from themselves. If absolutely everyone used strong and unique passwords on every site, then password hashing would be a lot less necessary. It would still have some value because there are use cases where a hacker might gain read-only access to a database dump, so hashed passwords can provide some protection against attackers getting actual access to your system in. However, if people used strong and unique passwords everywhere then password hashing would become more of a secondary concern instead of the absolutely-critical necessity it is today.



                So, if you can guarantee that every user of your system will only ever use strong and unique passwords (i.e. passwords that have not been used on other sites), then I think that even something simple like SHA2 would actually be a perfectly reasonable choice, regardless of whether or not better functions were available.



                BUT: changing business needs



                However, I would encourage you to double check your assumptions (that strong unique passwords will be the only ones ever in your system). I've seen business needs change to often in the past to rely on assumptions like that in critical business areas (which this may not be - obviously I don't know what this does). The problem is that business needs change. Maybe it's just me, but in my experience things that were meant to be temporary or limited to just a couple people inevitably turn into critical business applications used by everyone in the company, and all of a sudden you have a weak password scheme protecting critical business infrastructure. It won't always happen because people are trying to cut corners, but because 12 months down the road you forget that you didn't use a great password hash, or you leave and then next guy doesn't look into it, or you're under pressure to meet a deadline and you forget, or, or, or...



                In my experience businesses end up having security breaches not because security is hard but because they don't understand the need for spending time (aka money) on good security practices and cut corners where they shouldn't. Sure, right now a great password hashing scheme doesn't matter, but can you really guarantee that that won't change in the future? If you don't have time to put in proper password hashing now, can you guarantee that when the needs change and it suddenly does matter, that you will have time to do it right then?



                Of course at the end of the day every business needs to make money, and sometimes "Let's keep this simple for now to get this out the door" is a perfectly reasonable answer. Just be careful though because making that decision too often is how companies end up with systems filled with security holes. As a company you have to find that balance for yourself. The trouble is that when companies chronically skimp on the security it is ultimately their customers that hurt the most.






                share|improve this answer




















                • +1 for "things that were meant to be temporary or limited to just a couple people inevitably turn into critical business applications"
                  – Kelly Bang
                  Nov 20 at 21:23












                up vote
                3
                down vote










                up vote
                3
                down vote









                I agree with Mike and Royce in their answers, and don't feel the need to repeat what they covered well. However I wanted to more directly address this comment of yours:




                Additional Information: I will be the only one storing passwords on
                that system, so I can 1) guarantee that none of the passwords will be
                used twice and 2) ensure that the passwords will have a very high
                entropy.




                This piece of information is both important and not-important. Here's why:



                The case for password hashing



                It's always important to remember why we hash passwords, and it all boils down to password reuse. The reason why password hashing is so important is because when your system gets compromised and passwords are stolen, it isn't just access to your site that is compromised, but access to every site where your users have re-used the same email/password combination which (as we know) happens a lot. Password hashing is about protecting users from themselves. If absolutely everyone used strong and unique passwords on every site, then password hashing would be a lot less necessary. It would still have some value because there are use cases where a hacker might gain read-only access to a database dump, so hashed passwords can provide some protection against attackers getting actual access to your system in. However, if people used strong and unique passwords everywhere then password hashing would become more of a secondary concern instead of the absolutely-critical necessity it is today.



                So, if you can guarantee that every user of your system will only ever use strong and unique passwords (i.e. passwords that have not been used on other sites), then I think that even something simple like SHA2 would actually be a perfectly reasonable choice, regardless of whether or not better functions were available.



                BUT: changing business needs



                However, I would encourage you to double check your assumptions (that strong unique passwords will be the only ones ever in your system). I've seen business needs change to often in the past to rely on assumptions like that in critical business areas (which this may not be - obviously I don't know what this does). The problem is that business needs change. Maybe it's just me, but in my experience things that were meant to be temporary or limited to just a couple people inevitably turn into critical business applications used by everyone in the company, and all of a sudden you have a weak password scheme protecting critical business infrastructure. It won't always happen because people are trying to cut corners, but because 12 months down the road you forget that you didn't use a great password hash, or you leave and then next guy doesn't look into it, or you're under pressure to meet a deadline and you forget, or, or, or...



                In my experience businesses end up having security breaches not because security is hard but because they don't understand the need for spending time (aka money) on good security practices and cut corners where they shouldn't. Sure, right now a great password hashing scheme doesn't matter, but can you really guarantee that that won't change in the future? If you don't have time to put in proper password hashing now, can you guarantee that when the needs change and it suddenly does matter, that you will have time to do it right then?



                Of course at the end of the day every business needs to make money, and sometimes "Let's keep this simple for now to get this out the door" is a perfectly reasonable answer. Just be careful though because making that decision too often is how companies end up with systems filled with security holes. As a company you have to find that balance for yourself. The trouble is that when companies chronically skimp on the security it is ultimately their customers that hurt the most.






                share|improve this answer












                I agree with Mike and Royce in their answers, and don't feel the need to repeat what they covered well. However I wanted to more directly address this comment of yours:




                Additional Information: I will be the only one storing passwords on
                that system, so I can 1) guarantee that none of the passwords will be
                used twice and 2) ensure that the passwords will have a very high
                entropy.




                This piece of information is both important and not-important. Here's why:



                The case for password hashing



                It's always important to remember why we hash passwords, and it all boils down to password reuse. The reason why password hashing is so important is because when your system gets compromised and passwords are stolen, it isn't just access to your site that is compromised, but access to every site where your users have re-used the same email/password combination which (as we know) happens a lot. Password hashing is about protecting users from themselves. If absolutely everyone used strong and unique passwords on every site, then password hashing would be a lot less necessary. It would still have some value because there are use cases where a hacker might gain read-only access to a database dump, so hashed passwords can provide some protection against attackers getting actual access to your system in. However, if people used strong and unique passwords everywhere then password hashing would become more of a secondary concern instead of the absolutely-critical necessity it is today.



                So, if you can guarantee that every user of your system will only ever use strong and unique passwords (i.e. passwords that have not been used on other sites), then I think that even something simple like SHA2 would actually be a perfectly reasonable choice, regardless of whether or not better functions were available.



                BUT: changing business needs



                However, I would encourage you to double check your assumptions (that strong unique passwords will be the only ones ever in your system). I've seen business needs change to often in the past to rely on assumptions like that in critical business areas (which this may not be - obviously I don't know what this does). The problem is that business needs change. Maybe it's just me, but in my experience things that were meant to be temporary or limited to just a couple people inevitably turn into critical business applications used by everyone in the company, and all of a sudden you have a weak password scheme protecting critical business infrastructure. It won't always happen because people are trying to cut corners, but because 12 months down the road you forget that you didn't use a great password hash, or you leave and then next guy doesn't look into it, or you're under pressure to meet a deadline and you forget, or, or, or...



                In my experience businesses end up having security breaches not because security is hard but because they don't understand the need for spending time (aka money) on good security practices and cut corners where they shouldn't. Sure, right now a great password hashing scheme doesn't matter, but can you really guarantee that that won't change in the future? If you don't have time to put in proper password hashing now, can you guarantee that when the needs change and it suddenly does matter, that you will have time to do it right then?



                Of course at the end of the day every business needs to make money, and sometimes "Let's keep this simple for now to get this out the door" is a perfectly reasonable answer. Just be careful though because making that decision too often is how companies end up with systems filled with security holes. As a company you have to find that balance for yourself. The trouble is that when companies chronically skimp on the security it is ultimately their customers that hurt the most.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 19 at 17:49









                Conor Mancone

                9,47132145




                9,47132145











                • +1 for "things that were meant to be temporary or limited to just a couple people inevitably turn into critical business applications"
                  – Kelly Bang
                  Nov 20 at 21:23
















                • +1 for "things that were meant to be temporary or limited to just a couple people inevitably turn into critical business applications"
                  – Kelly Bang
                  Nov 20 at 21:23















                +1 for "things that were meant to be temporary or limited to just a couple people inevitably turn into critical business applications"
                – Kelly Bang
                Nov 20 at 21:23




                +1 for "things that were meant to be temporary or limited to just a couple people inevitably turn into critical business applications"
                – Kelly Bang
                Nov 20 at 21:23










                up vote
                2
                down vote














                I have to store passwords on a system which doesn't offer any of the algorithms recommended for hashing passwords (e.g. bcrypt, scrypt or PBKDF2). Would it be better to use an unsuitable algorithm (e.g. SHA-1 or SHA-2 family) before using none?




                The strict answer to your question is yes. The reason is that fast hashes won't protect weak passwords, but they will protect very strong ones, and that is strictly better than plaintext.



                However, if you have SHA-1 or SHA-2 there are are very few (if any!) excuses not to use PBKDF2. Yeah, the common advice is "don't roll your own crypto," but if you've got SHA-1 or SHA-2 that's already the key building block for PBKDF2, and for the case of password hashing writing your own implementation of PBKDF2 can hardly be worse than not. Here's the relevant RFC and section:



                • https://tools.ietf.org/html/rfc2898#section-5.2

                When they say "pseudorandom function" you should use some HMAC variant (ideally HMAC-SHA-512, but any of them will do). Your library likely already has HMAC implementations, but if it doesn't, password hashing is again a case where implementing your own can't be worse than not.






                share|improve this answer
























                  up vote
                  2
                  down vote














                  I have to store passwords on a system which doesn't offer any of the algorithms recommended for hashing passwords (e.g. bcrypt, scrypt or PBKDF2). Would it be better to use an unsuitable algorithm (e.g. SHA-1 or SHA-2 family) before using none?




                  The strict answer to your question is yes. The reason is that fast hashes won't protect weak passwords, but they will protect very strong ones, and that is strictly better than plaintext.



                  However, if you have SHA-1 or SHA-2 there are are very few (if any!) excuses not to use PBKDF2. Yeah, the common advice is "don't roll your own crypto," but if you've got SHA-1 or SHA-2 that's already the key building block for PBKDF2, and for the case of password hashing writing your own implementation of PBKDF2 can hardly be worse than not. Here's the relevant RFC and section:



                  • https://tools.ietf.org/html/rfc2898#section-5.2

                  When they say "pseudorandom function" you should use some HMAC variant (ideally HMAC-SHA-512, but any of them will do). Your library likely already has HMAC implementations, but if it doesn't, password hashing is again a case where implementing your own can't be worse than not.






                  share|improve this answer






















                    up vote
                    2
                    down vote










                    up vote
                    2
                    down vote










                    I have to store passwords on a system which doesn't offer any of the algorithms recommended for hashing passwords (e.g. bcrypt, scrypt or PBKDF2). Would it be better to use an unsuitable algorithm (e.g. SHA-1 or SHA-2 family) before using none?




                    The strict answer to your question is yes. The reason is that fast hashes won't protect weak passwords, but they will protect very strong ones, and that is strictly better than plaintext.



                    However, if you have SHA-1 or SHA-2 there are are very few (if any!) excuses not to use PBKDF2. Yeah, the common advice is "don't roll your own crypto," but if you've got SHA-1 or SHA-2 that's already the key building block for PBKDF2, and for the case of password hashing writing your own implementation of PBKDF2 can hardly be worse than not. Here's the relevant RFC and section:



                    • https://tools.ietf.org/html/rfc2898#section-5.2

                    When they say "pseudorandom function" you should use some HMAC variant (ideally HMAC-SHA-512, but any of them will do). Your library likely already has HMAC implementations, but if it doesn't, password hashing is again a case where implementing your own can't be worse than not.






                    share|improve this answer













                    I have to store passwords on a system which doesn't offer any of the algorithms recommended for hashing passwords (e.g. bcrypt, scrypt or PBKDF2). Would it be better to use an unsuitable algorithm (e.g. SHA-1 or SHA-2 family) before using none?




                    The strict answer to your question is yes. The reason is that fast hashes won't protect weak passwords, but they will protect very strong ones, and that is strictly better than plaintext.



                    However, if you have SHA-1 or SHA-2 there are are very few (if any!) excuses not to use PBKDF2. Yeah, the common advice is "don't roll your own crypto," but if you've got SHA-1 or SHA-2 that's already the key building block for PBKDF2, and for the case of password hashing writing your own implementation of PBKDF2 can hardly be worse than not. Here's the relevant RFC and section:



                    • https://tools.ietf.org/html/rfc2898#section-5.2

                    When they say "pseudorandom function" you should use some HMAC variant (ideally HMAC-SHA-512, but any of them will do). Your library likely already has HMAC implementations, but if it doesn't, password hashing is again a case where implementing your own can't be worse than not.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Nov 20 at 1:15









                    Luis Casillas

                    6,77721424




                    6,77721424




















                        up vote
                        1
                        down vote













                        To answer your question: yes, use the best algorithm you have access to. If you have several, you might combine them (note: concatenation of passwords, e.g. sha1(password)+md5sum(password), is more vulnerable to guessing, since an attacker could pick which hash they want to guess, but collisions are much less likely, since both passwords have to match. Do use random, different salt for each password.



                        You say your system "doesn't offer any of the algorithms recommended for hashing passwords". I would encourage you to reexamine that assumption.



                        Almost every modern programming language has implementations of secure hashes. You do not necessarily need it implemented in a pre-made, pre-installed library - for example, if your program is written in C, you should be able to find implementations of any hash in C, as a stand-alone function. Even tiny processors like Arduino have bcrypt and PBKDF2, off the shelf. The extra labour involved is minimal. You could even implement it yourself (but be very careful, and test very thoroughly!).



                        I do not doubt that there are exceptions, but there aren't many.






                        share|improve this answer
























                          up vote
                          1
                          down vote













                          To answer your question: yes, use the best algorithm you have access to. If you have several, you might combine them (note: concatenation of passwords, e.g. sha1(password)+md5sum(password), is more vulnerable to guessing, since an attacker could pick which hash they want to guess, but collisions are much less likely, since both passwords have to match. Do use random, different salt for each password.



                          You say your system "doesn't offer any of the algorithms recommended for hashing passwords". I would encourage you to reexamine that assumption.



                          Almost every modern programming language has implementations of secure hashes. You do not necessarily need it implemented in a pre-made, pre-installed library - for example, if your program is written in C, you should be able to find implementations of any hash in C, as a stand-alone function. Even tiny processors like Arduino have bcrypt and PBKDF2, off the shelf. The extra labour involved is minimal. You could even implement it yourself (but be very careful, and test very thoroughly!).



                          I do not doubt that there are exceptions, but there aren't many.






                          share|improve this answer






















                            up vote
                            1
                            down vote










                            up vote
                            1
                            down vote









                            To answer your question: yes, use the best algorithm you have access to. If you have several, you might combine them (note: concatenation of passwords, e.g. sha1(password)+md5sum(password), is more vulnerable to guessing, since an attacker could pick which hash they want to guess, but collisions are much less likely, since both passwords have to match. Do use random, different salt for each password.



                            You say your system "doesn't offer any of the algorithms recommended for hashing passwords". I would encourage you to reexamine that assumption.



                            Almost every modern programming language has implementations of secure hashes. You do not necessarily need it implemented in a pre-made, pre-installed library - for example, if your program is written in C, you should be able to find implementations of any hash in C, as a stand-alone function. Even tiny processors like Arduino have bcrypt and PBKDF2, off the shelf. The extra labour involved is minimal. You could even implement it yourself (but be very careful, and test very thoroughly!).



                            I do not doubt that there are exceptions, but there aren't many.






                            share|improve this answer












                            To answer your question: yes, use the best algorithm you have access to. If you have several, you might combine them (note: concatenation of passwords, e.g. sha1(password)+md5sum(password), is more vulnerable to guessing, since an attacker could pick which hash they want to guess, but collisions are much less likely, since both passwords have to match. Do use random, different salt for each password.



                            You say your system "doesn't offer any of the algorithms recommended for hashing passwords". I would encourage you to reexamine that assumption.



                            Almost every modern programming language has implementations of secure hashes. You do not necessarily need it implemented in a pre-made, pre-installed library - for example, if your program is written in C, you should be able to find implementations of any hash in C, as a stand-alone function. Even tiny processors like Arduino have bcrypt and PBKDF2, off the shelf. The extra labour involved is minimal. You could even implement it yourself (but be very careful, and test very thoroughly!).



                            I do not doubt that there are exceptions, but there aren't many.







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Nov 19 at 21:25









                            AMADANON Inc.

                            1,44369




                            1,44369




















                                up vote
                                0
                                down vote













                                YES, even low quality hash is much better than storing passwords in plaintext



                                If I understand you update, someone else will be doing the authentication (unrelated to you and your database), and you will use your password hash database only for duplicate password detection? Requirement of determining the password entropy would be based on plaintext, and is unrelated to storing password hashes, right?



                                Then you can store in your hash database just a small part of calculated sha2 hash of salt+plaintext (for example, storing only low 8 bytes of 32 bytes returned by sha256), which will be plenty enough to detect duplicates with no false positives in real life, but still not enough to allow the attacker to use rainbow tables to guess original password in case your database is stolen.



                                (Disclaimer: if you ARE doing authentication and not only duplicate password detection, than dropping part ot the hash would obviously be terrible idea!)






                                share|improve this answer
























                                  up vote
                                  0
                                  down vote













                                  YES, even low quality hash is much better than storing passwords in plaintext



                                  If I understand you update, someone else will be doing the authentication (unrelated to you and your database), and you will use your password hash database only for duplicate password detection? Requirement of determining the password entropy would be based on plaintext, and is unrelated to storing password hashes, right?



                                  Then you can store in your hash database just a small part of calculated sha2 hash of salt+plaintext (for example, storing only low 8 bytes of 32 bytes returned by sha256), which will be plenty enough to detect duplicates with no false positives in real life, but still not enough to allow the attacker to use rainbow tables to guess original password in case your database is stolen.



                                  (Disclaimer: if you ARE doing authentication and not only duplicate password detection, than dropping part ot the hash would obviously be terrible idea!)






                                  share|improve this answer






















                                    up vote
                                    0
                                    down vote










                                    up vote
                                    0
                                    down vote









                                    YES, even low quality hash is much better than storing passwords in plaintext



                                    If I understand you update, someone else will be doing the authentication (unrelated to you and your database), and you will use your password hash database only for duplicate password detection? Requirement of determining the password entropy would be based on plaintext, and is unrelated to storing password hashes, right?



                                    Then you can store in your hash database just a small part of calculated sha2 hash of salt+plaintext (for example, storing only low 8 bytes of 32 bytes returned by sha256), which will be plenty enough to detect duplicates with no false positives in real life, but still not enough to allow the attacker to use rainbow tables to guess original password in case your database is stolen.



                                    (Disclaimer: if you ARE doing authentication and not only duplicate password detection, than dropping part ot the hash would obviously be terrible idea!)






                                    share|improve this answer












                                    YES, even low quality hash is much better than storing passwords in plaintext



                                    If I understand you update, someone else will be doing the authentication (unrelated to you and your database), and you will use your password hash database only for duplicate password detection? Requirement of determining the password entropy would be based on plaintext, and is unrelated to storing password hashes, right?



                                    Then you can store in your hash database just a small part of calculated sha2 hash of salt+plaintext (for example, storing only low 8 bytes of 32 bytes returned by sha256), which will be plenty enough to detect duplicates with no false positives in real life, but still not enough to allow the attacker to use rainbow tables to guess original password in case your database is stolen.



                                    (Disclaimer: if you ARE doing authentication and not only duplicate password detection, than dropping part ot the hash would obviously be terrible idea!)







                                    share|improve this answer












                                    share|improve this answer



                                    share|improve this answer










                                    answered Nov 19 at 21:07









                                    Matija Nalis

                                    845612




                                    845612




















                                        up vote
                                        0
                                        down vote













                                        Yes, using a weak hash is better than none.



                                        I think you should also consider the administrative way. If you maintain the database (but are not allowed to change the structure, who knows why...) you should not see plain text passwords, even if you are the most integer person and would not do any harm with that information. Just like the proverb: Opportunity makes the thief.






                                        share|improve this answer








                                        New contributor




                                        Lithilion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                        Check out our Code of Conduct.





















                                          up vote
                                          0
                                          down vote













                                          Yes, using a weak hash is better than none.



                                          I think you should also consider the administrative way. If you maintain the database (but are not allowed to change the structure, who knows why...) you should not see plain text passwords, even if you are the most integer person and would not do any harm with that information. Just like the proverb: Opportunity makes the thief.






                                          share|improve this answer








                                          New contributor




                                          Lithilion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                          Check out our Code of Conduct.



















                                            up vote
                                            0
                                            down vote










                                            up vote
                                            0
                                            down vote









                                            Yes, using a weak hash is better than none.



                                            I think you should also consider the administrative way. If you maintain the database (but are not allowed to change the structure, who knows why...) you should not see plain text passwords, even if you are the most integer person and would not do any harm with that information. Just like the proverb: Opportunity makes the thief.






                                            share|improve this answer








                                            New contributor




                                            Lithilion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                            Check out our Code of Conduct.









                                            Yes, using a weak hash is better than none.



                                            I think you should also consider the administrative way. If you maintain the database (but are not allowed to change the structure, who knows why...) you should not see plain text passwords, even if you are the most integer person and would not do any harm with that information. Just like the proverb: Opportunity makes the thief.







                                            share|improve this answer








                                            New contributor




                                            Lithilion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                            Check out our Code of Conduct.









                                            share|improve this answer



                                            share|improve this answer






                                            New contributor




                                            Lithilion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                            Check out our Code of Conduct.









                                            answered Nov 20 at 8:19









                                            Lithilion

                                            6211212




                                            6211212




                                            New contributor




                                            Lithilion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                            Check out our Code of Conduct.





                                            New contributor





                                            Lithilion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                            Check out our Code of Conduct.






                                            Lithilion is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                            Check out our Code of Conduct.




















                                                up vote
                                                0
                                                down vote













                                                Yes, it's definitively better to use a simple hash than none (though seeing how you apparently implement the system, I fail to see what's hindering you from doing things properly).



                                                However, given your "Additional information" edit, one might so bold as to say that you do not even need salt! That doesn't mean it's a good design and I wouldn't recommend that, but if you are serious about your guarantees, a simple secure hash of reasonable size is enough, strictly speaking.



                                                Why does one make such a fuss about password storage in the first place? Usually, passwords are low-entropy, and even when hashed there's a fair chance of guessing a password, even moreso as hash functions are very fast, trivially parallelizable, and there exist rainbow tables which provide a cheap shortcut. So even being unreadable after being hashed, this doesn't necessarily mean that passwords are unrecoverable.

                                                In principle, given infinite time, you could recover every password on every system (or at least a password that will work). That's just a consequence of the fact that there is a finite number of outputs to a hash function. So, in a quasi-exhaustive search, some input sequence must necessarily produce an output that works.

                                                Luckily attackers do not have infinite time, so our job is to make sure they don't have a reasonable chance of finding an input sequence that works within finite time, and with a finite supply of energy.



                                                Now... you say that you are the only user and you can guarantee that passwords are random and high entropy. This rules out most of the concerns about guessing.



                                                Given a "reasonable" digest size, that means that the chance of finding the hash in a rainbow table is minimal (zero, more or less), and the chance of finding it by brute force is equally more or less zero. There's no way someone will break SHA-256 digest brute force, let alone SHA-512. That idea simply isn't compatible with our understanding of how physics work.

                                                If the digest is large enough, and passwords are guaranteed (as you state) to be unique, random, high entropy... then actually you're just good to go with hashing once.



                                                Now of course, normally a system should work reliably even if you cannot provide that guarantee (or any guarantee for that matter). Thus, it's not the very best design.






                                                share|improve this answer
























                                                  up vote
                                                  0
                                                  down vote













                                                  Yes, it's definitively better to use a simple hash than none (though seeing how you apparently implement the system, I fail to see what's hindering you from doing things properly).



                                                  However, given your "Additional information" edit, one might so bold as to say that you do not even need salt! That doesn't mean it's a good design and I wouldn't recommend that, but if you are serious about your guarantees, a simple secure hash of reasonable size is enough, strictly speaking.



                                                  Why does one make such a fuss about password storage in the first place? Usually, passwords are low-entropy, and even when hashed there's a fair chance of guessing a password, even moreso as hash functions are very fast, trivially parallelizable, and there exist rainbow tables which provide a cheap shortcut. So even being unreadable after being hashed, this doesn't necessarily mean that passwords are unrecoverable.

                                                  In principle, given infinite time, you could recover every password on every system (or at least a password that will work). That's just a consequence of the fact that there is a finite number of outputs to a hash function. So, in a quasi-exhaustive search, some input sequence must necessarily produce an output that works.

                                                  Luckily attackers do not have infinite time, so our job is to make sure they don't have a reasonable chance of finding an input sequence that works within finite time, and with a finite supply of energy.



                                                  Now... you say that you are the only user and you can guarantee that passwords are random and high entropy. This rules out most of the concerns about guessing.



                                                  Given a "reasonable" digest size, that means that the chance of finding the hash in a rainbow table is minimal (zero, more or less), and the chance of finding it by brute force is equally more or less zero. There's no way someone will break SHA-256 digest brute force, let alone SHA-512. That idea simply isn't compatible with our understanding of how physics work.

                                                  If the digest is large enough, and passwords are guaranteed (as you state) to be unique, random, high entropy... then actually you're just good to go with hashing once.



                                                  Now of course, normally a system should work reliably even if you cannot provide that guarantee (or any guarantee for that matter). Thus, it's not the very best design.






                                                  share|improve this answer






















                                                    up vote
                                                    0
                                                    down vote










                                                    up vote
                                                    0
                                                    down vote









                                                    Yes, it's definitively better to use a simple hash than none (though seeing how you apparently implement the system, I fail to see what's hindering you from doing things properly).



                                                    However, given your "Additional information" edit, one might so bold as to say that you do not even need salt! That doesn't mean it's a good design and I wouldn't recommend that, but if you are serious about your guarantees, a simple secure hash of reasonable size is enough, strictly speaking.



                                                    Why does one make such a fuss about password storage in the first place? Usually, passwords are low-entropy, and even when hashed there's a fair chance of guessing a password, even moreso as hash functions are very fast, trivially parallelizable, and there exist rainbow tables which provide a cheap shortcut. So even being unreadable after being hashed, this doesn't necessarily mean that passwords are unrecoverable.

                                                    In principle, given infinite time, you could recover every password on every system (or at least a password that will work). That's just a consequence of the fact that there is a finite number of outputs to a hash function. So, in a quasi-exhaustive search, some input sequence must necessarily produce an output that works.

                                                    Luckily attackers do not have infinite time, so our job is to make sure they don't have a reasonable chance of finding an input sequence that works within finite time, and with a finite supply of energy.



                                                    Now... you say that you are the only user and you can guarantee that passwords are random and high entropy. This rules out most of the concerns about guessing.



                                                    Given a "reasonable" digest size, that means that the chance of finding the hash in a rainbow table is minimal (zero, more or less), and the chance of finding it by brute force is equally more or less zero. There's no way someone will break SHA-256 digest brute force, let alone SHA-512. That idea simply isn't compatible with our understanding of how physics work.

                                                    If the digest is large enough, and passwords are guaranteed (as you state) to be unique, random, high entropy... then actually you're just good to go with hashing once.



                                                    Now of course, normally a system should work reliably even if you cannot provide that guarantee (or any guarantee for that matter). Thus, it's not the very best design.






                                                    share|improve this answer












                                                    Yes, it's definitively better to use a simple hash than none (though seeing how you apparently implement the system, I fail to see what's hindering you from doing things properly).



                                                    However, given your "Additional information" edit, one might so bold as to say that you do not even need salt! That doesn't mean it's a good design and I wouldn't recommend that, but if you are serious about your guarantees, a simple secure hash of reasonable size is enough, strictly speaking.



                                                    Why does one make such a fuss about password storage in the first place? Usually, passwords are low-entropy, and even when hashed there's a fair chance of guessing a password, even moreso as hash functions are very fast, trivially parallelizable, and there exist rainbow tables which provide a cheap shortcut. So even being unreadable after being hashed, this doesn't necessarily mean that passwords are unrecoverable.

                                                    In principle, given infinite time, you could recover every password on every system (or at least a password that will work). That's just a consequence of the fact that there is a finite number of outputs to a hash function. So, in a quasi-exhaustive search, some input sequence must necessarily produce an output that works.

                                                    Luckily attackers do not have infinite time, so our job is to make sure they don't have a reasonable chance of finding an input sequence that works within finite time, and with a finite supply of energy.



                                                    Now... you say that you are the only user and you can guarantee that passwords are random and high entropy. This rules out most of the concerns about guessing.



                                                    Given a "reasonable" digest size, that means that the chance of finding the hash in a rainbow table is minimal (zero, more or less), and the chance of finding it by brute force is equally more or less zero. There's no way someone will break SHA-256 digest brute force, let alone SHA-512. That idea simply isn't compatible with our understanding of how physics work.

                                                    If the digest is large enough, and passwords are guaranteed (as you state) to be unique, random, high entropy... then actually you're just good to go with hashing once.



                                                    Now of course, normally a system should work reliably even if you cannot provide that guarantee (or any guarantee for that matter). Thus, it's not the very best design.







                                                    share|improve this answer












                                                    share|improve this answer



                                                    share|improve this answer










                                                    answered Nov 20 at 9:05









                                                    Damon

                                                    2,806715




                                                    2,806715




















                                                        up vote
                                                        0
                                                        down vote













                                                        Yeah you should be fine. SHA1 and 2 are still pretty strong for storing high entropy password hashes and will provide adequate protection from brute forcing. SHA2 provides better protection than SHA1.The vulnerabilities in SHA2 arn't relevant for this scenario since they relate to creating collisions where the initial plaintext is already known.






                                                        share|improve this answer








                                                        New contributor




                                                        Jake is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                        Check out our Code of Conduct.





















                                                          up vote
                                                          0
                                                          down vote













                                                          Yeah you should be fine. SHA1 and 2 are still pretty strong for storing high entropy password hashes and will provide adequate protection from brute forcing. SHA2 provides better protection than SHA1.The vulnerabilities in SHA2 arn't relevant for this scenario since they relate to creating collisions where the initial plaintext is already known.






                                                          share|improve this answer








                                                          New contributor




                                                          Jake is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                          Check out our Code of Conduct.



















                                                            up vote
                                                            0
                                                            down vote










                                                            up vote
                                                            0
                                                            down vote









                                                            Yeah you should be fine. SHA1 and 2 are still pretty strong for storing high entropy password hashes and will provide adequate protection from brute forcing. SHA2 provides better protection than SHA1.The vulnerabilities in SHA2 arn't relevant for this scenario since they relate to creating collisions where the initial plaintext is already known.






                                                            share|improve this answer








                                                            New contributor




                                                            Jake is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                            Check out our Code of Conduct.









                                                            Yeah you should be fine. SHA1 and 2 are still pretty strong for storing high entropy password hashes and will provide adequate protection from brute forcing. SHA2 provides better protection than SHA1.The vulnerabilities in SHA2 arn't relevant for this scenario since they relate to creating collisions where the initial plaintext is already known.







                                                            share|improve this answer








                                                            New contributor




                                                            Jake is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                            Check out our Code of Conduct.









                                                            share|improve this answer



                                                            share|improve this answer






                                                            New contributor




                                                            Jake is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                            Check out our Code of Conduct.









                                                            answered Nov 20 at 19:49









                                                            Jake

                                                            101




                                                            101




                                                            New contributor




                                                            Jake is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                            Check out our Code of Conduct.





                                                            New contributor





                                                            Jake is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                            Check out our Code of Conduct.






                                                            Jake is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                            Check out our Code of Conduct.




















                                                                up vote
                                                                0
                                                                down vote













                                                                To go along with the excellent answers above, I want to give a complimentary but contrary answer:



                                                                No. Using a weak hash is worse than not using a hash at all.



                                                                A weak hash gives you the illusion of security.



                                                                While you and your managers might understand currently that the hash offers no real security, a manager or developer down the line may think the hash is secure. These people may decide to store additional information using the hash in question.



                                                                There is also the risk where management may not simply understand that the hash is not secure to begin with. When faced with a decision to invest in security development, they may decide "the current system is good enough" because it is hashed already, and hashing is considered best practice.






                                                                share|improve this answer








                                                                New contributor




                                                                Gregroy Currie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                Check out our Code of Conduct.





















                                                                  up vote
                                                                  0
                                                                  down vote













                                                                  To go along with the excellent answers above, I want to give a complimentary but contrary answer:



                                                                  No. Using a weak hash is worse than not using a hash at all.



                                                                  A weak hash gives you the illusion of security.



                                                                  While you and your managers might understand currently that the hash offers no real security, a manager or developer down the line may think the hash is secure. These people may decide to store additional information using the hash in question.



                                                                  There is also the risk where management may not simply understand that the hash is not secure to begin with. When faced with a decision to invest in security development, they may decide "the current system is good enough" because it is hashed already, and hashing is considered best practice.






                                                                  share|improve this answer








                                                                  New contributor




                                                                  Gregroy Currie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                  Check out our Code of Conduct.



















                                                                    up vote
                                                                    0
                                                                    down vote










                                                                    up vote
                                                                    0
                                                                    down vote









                                                                    To go along with the excellent answers above, I want to give a complimentary but contrary answer:



                                                                    No. Using a weak hash is worse than not using a hash at all.



                                                                    A weak hash gives you the illusion of security.



                                                                    While you and your managers might understand currently that the hash offers no real security, a manager or developer down the line may think the hash is secure. These people may decide to store additional information using the hash in question.



                                                                    There is also the risk where management may not simply understand that the hash is not secure to begin with. When faced with a decision to invest in security development, they may decide "the current system is good enough" because it is hashed already, and hashing is considered best practice.






                                                                    share|improve this answer








                                                                    New contributor




                                                                    Gregroy Currie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                    Check out our Code of Conduct.









                                                                    To go along with the excellent answers above, I want to give a complimentary but contrary answer:



                                                                    No. Using a weak hash is worse than not using a hash at all.



                                                                    A weak hash gives you the illusion of security.



                                                                    While you and your managers might understand currently that the hash offers no real security, a manager or developer down the line may think the hash is secure. These people may decide to store additional information using the hash in question.



                                                                    There is also the risk where management may not simply understand that the hash is not secure to begin with. When faced with a decision to invest in security development, they may decide "the current system is good enough" because it is hashed already, and hashing is considered best practice.







                                                                    share|improve this answer








                                                                    New contributor




                                                                    Gregroy Currie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                    Check out our Code of Conduct.









                                                                    share|improve this answer



                                                                    share|improve this answer






                                                                    New contributor




                                                                    Gregroy Currie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                    Check out our Code of Conduct.









                                                                    answered yesterday









                                                                    Gregroy Currie

                                                                    1091




                                                                    1091




                                                                    New contributor




                                                                    Gregroy Currie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                    Check out our Code of Conduct.





                                                                    New contributor





                                                                    Gregroy Currie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                    Check out our Code of Conduct.






                                                                    Gregroy Currie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                    Check out our Code of Conduct.



























                                                                         

                                                                        draft saved


                                                                        draft discarded















































                                                                         


                                                                        draft saved


                                                                        draft discarded














                                                                        StackExchange.ready(
                                                                        function ()
                                                                        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f197994%2fis-it-better-to-use-an-unsuitable-hashing-algorithm-instead-of-none-at-all%23new-answer', 'question_page');

                                                                        );

                                                                        Post as a guest















                                                                        Required, but never shown





















































                                                                        Required, but never shown














                                                                        Required, but never shown












                                                                        Required, but never shown







                                                                        Required, but never shown

































                                                                        Required, but never shown














                                                                        Required, but never shown












                                                                        Required, but never shown







                                                                        Required, but never shown






                                                                        Popular posts from this blog

                                                                        How to check contact read email or not when send email to Individual?

                                                                        Displaying single band from multi-band raster using QGIS

                                                                        How many registers does an x86_64 CPU actually have?