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!
Does anyone know about what type of encryption is used to store data securely on CouchDB? How one can change/control this encryption mechanism for data security on CouchDB?
CouchDB does not encrypt data at rest (except passwords, by way of a PBKDF2 one-way hash).
It does allow the encryption of data in transit, by use of HTTPS, but for at-rest encryption, your options are:
Device/filesystem-level encryption. This is handled by your OS, and is completely invisible to CouchDB (and all other apps).
Application-level encryption. You can have your application encrypt data before marshaling it to JSON for storage in CouchDB. The crypto-pouch plugin is one example of this, which works for PouchDB (Note: I've never used it, so can't vouch for its usefulness).
While MD5 is no longer a recommended cryptography option for hashing (from what I learned), what is the rationale behind Spring Security implementing it to hash the OAuth and Refresh tokens before storing them to data store? Static code analysis tools run against our code base have raised usage of MD5 as PCI non-compliance. What could be the justification to ignore this if I have to? Is Spring planning to roll out an update with a different hashing algorithm? Our refresh tokens are set to live for a day and OAuth tokens for 30 minutes, if that helps.
MD5 is not being used here for any cryptographic properties, just as a way to generate a unique key (and unless you are minting more tokens than there are atoms in the universe I doubt it will cause problems).
I need to use one of the encryption algorithms say DES encryption to store all the data in my Drupal database. Is there a way I can do that? Based on my understanding there needs to go some encrypt/decrypt functions in all database calls from the code?
Have a look at http://drupal.org/project/encrypt it might be worth a try.
Encrypt
Encrypt is a Drupal module that provides an application programming
interface (API) for performing two-way data encryption. It allows
modules to encrypt data such that it can be decrypted using the same
key that was used to encrypt the data. This is useful for storing
sensitive information.
There is no native way to do two-way encryption in Drupal. There is
also not a very standard way of performing encryption in PHP without
extensions. This module aims to make it easy for other modules to keep
data secured in an extensible way that does not inherently require any
other dependencies.
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).