1. Password hashing // lack of cryptographic hash functions
- Posted by CoJaBo2 Jul 18, 2012
- 1508 views
Just as an FYI, nobody should be using anything other than proven methods - such as salted SHA256 - to hash passwords. (MD5 is still the most commonly used today, but MD5 was been broken several years ago, and should no longer be used in new software)
prompt_password() #6, for example, demonstrates precisely what not to do- create a new algorithm without rigorous testing and knowledge of numerous pitfalls; at a quick glance, it looks like it will create some extremely poor hashes (no offense meant, but this demonstrates a very important point- most people wouldn't be able to recognize this as weak, and most - me included - wouldn't be able to come up with a stronger one either!). A custom algo really shouldn't be used for anything requiring even very modest security. Its just simpler to do it the right way, and use something already in wide use.
Or at least it should be- I can't help but notice that Eu's documentation doesn't have any cryptographic hashing functions at all (other than a brief note saying they aren't implemented). Since this one of the more common things needed to do (anything that wants to be password protected needs it), it really should be a priority. This shouldn't be hard to do either, there is plenty of code in C that could be integrated into the backend (or ported if need be). (I'd certainly lend help testing, etc, but I don't currently have time or familiarity with the backend to submit a patch to add this)
(Aside: The title of this page is "Fork Messsage")
2. Re: Password hashing // lack of cryptographic hash functions
- Posted by ne1uno Jul 19, 2012
- 1423 views
Just as an FYI, nobody should be using anything other than proven methods - such as salted SHA256 - to hash passwords. (MD5 is still the most commonly used today, but MD5 was been broken several years ago, and should no longer be used in new software)
echo all the above and a few other points.
using a salt to make a password less guessable helps, providing it can't be trivially reconstructed. (can't recall if the pw hasher has a salt, wouldn't be surprised) note: cryptographically correct random number generators are nearly impossible to create. same rules as custom hashes and crypto algo. fully open source and vetted code. security by obscurity is of limited value.
because you really need a hardware generated random number source. intuition is not reliable. for instance, running the hash through another hash should be more secure, right? check bugtraq if you have any doubts.
even if uncrackable directly, a brute force or a dictionary attack can compare non salted hash in seconds to minutes on a single pc and from hours to days for under 12 mixed character passwords.
you should be using pass phrases at least 12 characters mixed case and punctuation on any password that matters. do any not?
posting the hash or algo here or on sci.crypt and asking or worse, daring anyone to crack it is not really useful. if someones data is worth getting into, it will be done one way or another, sooner or later. leaving the lawyers to assign liability and collect their fees.
3. Re: Password hashing // lack of cryptographic hash functions
- Posted by CoJaBo2 Jul 19, 2012
- 1361 views
A salt is something different than that; Wikipedia explains it well: http://en.wikipedia.org/wiki/Salt_%28cryptography%29
I tend to use a format like sha256hash( concat( secret_value, user_name, user_password ) ) for mine; The secret value prevents anyone from using a pre-computed rainbow-table to crack any of the passwords (an operation that would take milliseconds if the user password is in the table). It doesn't strictly need to be secret, but it should be different across different databases. The presence of the user name prevents analysis of the database to find duplicate passwords (e.g., an attacker won't be able to find out that 3% of the member base is using the same password just by looking at the hashes).
As far as passwords go, a passphrase is a far better choice than messing around with special characters; XKCD does a very good job of explaining why: http://xkcd.com/936/
In that case, a 4-word passphrase is 65,536 times harder to brute-force than a typical 11 character password, and much easier to remember.
I've done some trivial testing on that hash algo in the other post, and suspicion confirmed that it has a high collision rate; .0249%. For comparison, that is roughly 64 orders of magnitude worse than an ideal cryptographic hash of the same size.
I've actually also cracked several of the "encryption" libs in the archives, many of which were downright trivial.
The only one that even seems to attempt to implement real crypto is the Blowfish one, but it only supports encrypting files, and implements CBC incorrectly (the IV is always 0).
Several of them are also shrouded, and wont run on any version of Eu that is still available to download; these I couldn't test at all.
Most OSs already implement hashing and encryption (SHA2, AES, etc), all that is realy needed is a wrapper. The only issue with that anything pre-XP SP3 is missing some of the modern ones (notably, SHA2).
