Jtdylktuy

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.

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).

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.]

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.

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.

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.

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.

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!)

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.

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.

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.

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.