I am trying to decide the best hashing algorithm for my password encryption.
When I go to PBKDF2 page, I can clearly see that it accepts salt and number of iterations, and indeed I can provide both of them in my node.js script. Similar situation is with Bcrypt, it has salt and number of iterations.
But when I go to SHA wiki then I can't find even a mention of salting or giving number of iterations. SHA doesn't have salting then? But from time to time I stumble upon links on the Internet that do talk about SHA salting.
Sorry if the question is stupid, but I am genuinely confused with all this crypto algorithms.
p.s. I use node.js to play around with those algorithms
I had not touch crypto algorithms in a while but i'm sure you can use hashes in Secure Hash Algorithm from the family of hash functions SHA-2 and also in SHA-3, being called Salted Secure Hash Algorithm or SSHA.
Depending on how secure you want it to be, SSHA-256 is far more secure than SHA-256 but Secure Hash Algorithm are not recommended for your purpose, due of they intend to be fast and they lack on password encryption being vulnerable to brute force and dict attacks.
For it, you need something designed to be difficult to serialize and/or optimize, that requires loads of workload.
Argon2, BCrypt or PBKDF2 are the safest options in terms of password encryption.
In case you want some theorical approach and further understanding of the topic, you can check the following post: https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/
Have a nice day!
Related
So I just got my first Computer with MacOS (never used MacOS, idk anything). I am trying to make a password manager which stores all my data (usernames, emails, passwords etc.) so I only need to remember one MasterPassword.
All the Data is AES encrypted with that MasterPassword and the hash of that Password is currently stored in a .txt file. Now I am thinking: What if someone just puts his own hash into that file and just logs into the program ?
How do I store this hash safely?
In general, the number one rule of crypto is "never roll your own crypto". (never write your own system to be secure when somebody else has already written one.) There are a number of reasons for this, but the most obvious is that even if you are very smart, an established package will have had more smart eyes on it to patch any security issues you might have missed.
If you want to safely store your data, use a password manager that is well-established.
If you want to make a password manager as a personal project though, here are some things to consider.
The most secure way to store a hash is to not store it at all. If you're AES encrypting your data, the way to verify that it has been decrypted is that the decrypted plaintext is correct. That way, you don't need to store anything regarding the password at all.
You want to salt your hashes so that common passwords do not lead to common hashes. The SHA-512 sum for password is 9151440965cf9c5e07f81eee6241c042a7b78e9bb2dd4f928a8f6da5e369cdffdd2b70c70663ee30d02115731d35f1ece5aad9b362aaa9850efa99e3d197212a. Here are the google search results for that string. If we instead hash password+EsistDerPascal K we get a string that returns no google search results. See the link for standard hashing techniques.
Use a proper cryptographic hash. While many things still use SHA-512 others have moved to bcrypt or other algorithms. If you're here from the future and Ubuntu isn't using SHA-512, don't use it.
You want your hash (and salt) to be only readable by users who should be able to use it. The easiest thing here is probably using chmod 600 to restrict read/write of the file to your user (or another user, or root).
This is an incomplete list and you should not rely upon any of the above to protect sensitive information.
The site I'm working on right now uses a third-party billing company that handles user sign-ups, so all user names and passwords are entered in the biller's site, then the biller writes the username and the user's now encrypted password to a 'members' database on our server.
The problem is that the biller (and many of them, from what I gather) encrypts the passwords with MD5 which I have read over and over is NOT secure. But, as the encryption is handled at the biller's end, and they are only offering MD5, I wanted to know if there was anything I could do on my end to make the passwords more secure?
As I'm writing this, I'm thinking that, 'If the biller is encrypting the passwords, there's probably no way for me to add more security' because part of the biller's job is to handle member issues such as lost passwords and other issues.
So...is there a way to add more security to the passwords the biller stores in our DB or do we just take our chances with what we all know is an unsafe standard? We're stuck with this biller for the short term, and what's worse, I contacted another biller who is very well known and they use MD5 as well.
Many thanks in advance!
Unfortunately, there's not a lot you can do about the biller at this stage. It's difficult to know what threats you're trying to mitigate against. If you're worried about the communication between the biller and your machines being monitored then SSL or SSH should help with that. If you're worried about an attacker breaking into your database and stealing passwords, then using a different scheme to store the passwords in will help.
You can either stick with MD5 and add a salt. Please check that your biller is salting their passwords, if they're not you really need to get rid of them. They're database will be vulnerable to rainbow table lookups.
A rainbow table is a precomputed table for reversing cryptographic hash functions, usually for cracking password hashes
You could take the MD5s you receive and use a better password hashing algorithm (assuming you don't need to keep the original MD5). One example is bcrypt. Note that SHA1, SHA-256, etc. whilst better hashing algorithms are not that great at password hashing. The reason is that SHA is designed to be fast. You want password hashing to be relatively slow. For legitimate users, waiting 20ms for a correct password validation is no time at all, but for an attacker it drastically reduces their ability to brute force a password.
bcrypt is a key derivation function for passwords designed by Niels Provos and David Mazières, based on the Blowfish cipher, and presented at USENIX in 1999.[1] Besides incorporating a salt to protect against rainbow table attacks, bcrypt is an adaptive function: over time, the iteration count can be increased to make it slower, so it remains resistant to brute-force search attacks even with increasing computation power.
Essentially, bcrypt has a good hashing algorithm, requires a salt and lets you specify the number of times the hashing algorithm is run on it. You could, for example, start off with 100 rounds. In two years time when computing power has increased you can then increase that to 150.
Md5 is technically a hasing algorithm, not an encryption algorithm. The difference being that you cannot unhash a a hashed string (in theory, md5 is weak because this was proven false). You can undo encrypting if you have the appropriate key.
What is your biggest concern? Are you worried about someone intercepting the passwords as they travel between you and the biller or are you worried about someone opening the database?
If you are worried about someone breaking into your database and getting your table with passwords, then you can definitely improve the security. You could encrypt the entries before you persist them using a modern algorithm with your own private key. Don't store the key with the server and unencrypt when pulling out of the database before using the md5 value.
You could also, just hash the md5 value they give you (and use a salt) with some modern strong hashing algorithm. This means that if anyone gets your table, they will have to unhash your hash, then unhash the md5. Presumably you would use a strong hash and the first step would be impossible. As always, be careful with security as you most certainly should write something yourself, you will have bugs!
I just read an article. And it's said:
So I’m not saying salts are without purpose, I’m saying that they
don’t prevent dictionary or brute force attacks (which they don’t).
If you have a database dump, with hashed passwords and salts, you can start brute force only if you know crypt algorithm. If you use open source, it can be a problem. But if you change algorithm a little, it's not a problem, until somebody know it. Am I right?
Troy Hunt recently wrote an excellent article, Our password hashing has no clothes, detailing the evolution of password hashing, including Salts.
Although Salts prevented direct comparisons with pre-hashed rainbow tables, his point is that hardware has improved to the point where applying the salt to an unhashed rainbow password and comparing salted hashes can now be done in a short time due to Moore's law.
As Trickfire states, using a proprietary hashing algorithm is security through obscurity. If the attacker has your database, he will also likely be able to get your app and disassemble it and obtain the algorithm.
Security through obscurity
While it makes the problem of figuring out the password a little harder, relying on this technique is not suggested.
In ColdFusion, What is the best best of doing a user login password comparison with the database that will encrypt the password between the client and server?
I noticed there's a javascript version at http://pajhome.org.uk/crypt/md5/index.html
but what can be done for users without javascript enabled?
These points are not specific to coldfusion, but I feel I must state them:
Do the hash server-side.
The point of hashing is to make it really hard to figure out what to send the server in order to produce the string it matches with the DB. If you just match the string given by the client with the DB entry, you're defeating the purpose.
Don't use MD5.
It's broken. There are ways to defeat it. Don't use it.
If you're worried about the password being exposed on the way to the server, use TLS.
TLS is designed for making communications between a client and a server opaque to anyone else. The biggest problem with it is the recent BEAST attack, which won't work if you implement it right.
Use a secure hash like SHA-256.
As far as we know, SHA-256 is pretty damn secure. The best known attack on it reduces the time complexity by 2 bits, which doesn't make an attack practical.
Use a random salt, unique to each user.
A precomputed rainbow table for 2^50-bit space would take 256 petabytes of storage, and one for 2^256 space would take an enormous amount more. However, due to the Birthday Problem, it's conceivable that some of your users' accounts could be compromised if you do not salt their hashes.
Hash multiple times. On the order of thousands of times.
If your DB is compromised, a hash might mean that your average user's password is found in years. If you has thousands of times, that would mean thousands of years.
Some additional points, to address misconceptions it looks like you have:
A cryptographic hash is one-way. You can't decrypt it. If you find a practical way to decrypt it, then you will become rich and (in)famous.
Standard HTTP is not secure. Anyone can eavesdrop and intercept your password that is being POSTed in plaintext, or hashed. If your server doesn't demand an encrypted connection for sensitive data, you're asking for a replay attack (http://en.wikipedia.org/wiki/Replay_attack).
You can make your own SSL certificate. If you're worried about your users seeing "this SSL Cert is self signed! Oh noes!" and being scared off, either do without and take the risk, or cough up the cash.
I have an ASP.Net web application where I would like to implement cryptography for password security. I am not using SSL.
For that i studied and pick CRAM-MD5 algorithm for password authentication. I have implement javascript cram-md5 algorthim available at http://pajhome.org.uk/crypt/md5/
Here i would like to know that is there anyone used it and face that CRAM-MD5 authentication is decoded by hackers?
What are the possiblities of decoding CRAM-MD5 authentication?
MD5 is no longer considered secure, see MD5 vulnerabilities. For a more secure implementation, choose a different hash algorithm (such as SHA-256 or better).
For sure MD5 is no longer considered secure but the cryptanalysis vulnerabilities affecting him does not affect HMAC-MD5. It's a whole different beast.
I do agree that CRAM-MD5 would not be the best recommendation but it really has nothing to do with the insecurity of MD5.
Learn what's the difference.
See http://www.openauthentication.org/pdfs/Attacks%20on%20SHA-1.pdf, https://www.rfc-editor.org/rfc/rfc6151 and http://cseweb.ucsd.edu/~mihir/papers/hmac-new.html
Contrary to what others are saying, CRAM-MD5 is standard and safe to use. It's widely used in SASL for IMAP/SMTP authentication. You might be reading your EMail using CRAM-MD5. The other standard hashing algorithms are HTTP Digest Authentication and CHAP used in PPP but they all uses MD5 due to historical reasons. You can choose more secure SHA1-based hash but you will have to roll your own challenge schemes.
Because it uses challenge/response scheme, it's less vulnerable to the weakness of the MD5 hash. Unless you have special security requirements, stay with one of the standard algorithms.
Don't self implement your hashing algorithm. There are well tested implementations in System.Security. As stated don't use MD5.
In addition you should salt your hashes. For example if you have a user table with a password field you can add a salt field that is simply an integer, or a guid, or even a timestamp, but something unique. The salt ensures you will not have hash collisions within your database. Here is a discussion on salting.
Implementing your own cryptography is generally seen as a bad idea.
Cryptographic algorithms have a lot of very specific demands, and if even one of them isn't met (and that usually happens when people do their own), it usually won't be all too much more secure than no crypto at all.
If you're not convinced, this Google Tech Talk should help.
From Wiki:
Protocol Weaknesses
- No mutual authentication; client does not verify server.
- Offline dictionary attack to recover password feasible after capturing a successful CRAM-MD5 protocol exchange.
- Use of MD5 insufficient.
- Carries server requirement for storage of reversibly encrypted passwords.
I'd be scared to use md5 hashing algorithm, as getting back the original password from hash can be done in few seconds, if password wasn't long enough (actually, you can google for md5 rainbow table, there are sites that will decode such hash in few seconds and give back the result ;) ).
As others have advised; don't use MD5, ever, for anything.
But as to an actual answer, how badly is it broken:
Well, with any one-hash it's, well, one-way, so you can't 'decode' it in that sense. What you can do, however, is generate collisions much faster than is acceptable. This allows the attackers to force matches in things that wouldn't otherwise match. It makes any validation of inference of the type 'md5(this) = md5(that) so this = that' wrong. This breaks digital signatures, and all sorts of other things.
Stay away from MD5, in any form.
-- Edit
Oh, and just a note, that hashing the password is no replacement for SSL. SSL is used to ensure, to the client, that the site they are browsing is yours, and to protect general sending of data.
Hashing is about protecting your database from a possible compromise. (And you always need to hash with a salt; you store the salt right next to the username in the db).