Ftyjtk

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.

Edit based on comments:

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 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 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 users an uncrackable password like 'SDXBZsRVBKVnXznpLTBMIKhTX' or 'afferently-imitatee-snowmelt-heirdom-leeching' ... even a weak hash like SHA1 will put that password out of reach.

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.

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.

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

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.

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.