As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have an app which requires keeping multiple user passwords, with the requirement that they be recoverable.
I'm thinking about encrypting the passwords using the master password + another encryption mechanism.
The key for the encryption will be kept in an external system and can be retrieved using an API. The thing is i'm not sure if:
This method is secure enough
which additional mechanism should i choose for the encryption.
Thanks.
EDIT--------------
I know it's closed...but i do want to clarify - i have to have the ability to decrypt, this is a major part in my app...with that been said i think i got my answer with AES algo. I dont need hashing since hashing is irreversible
Stack overflow is a forum for helping you with coding issues.
This question is more suited to The security forum.
That said, there are some standardized guidelines for encryption.
When implementing a symmetric encryption cipher, it's best to use the AES Algorithm. This is the most secure symmetric key block cipher to date, and is the standard for what we currently consider as "protected".
If you're looking to hash passwords, which is the standard for password storage, then there is no need for a key. Use the SHA1 algorithm. In terms of the size of the output, it is the more secure hashing algorithm that is currently in use. Other options are SHA256 and SHA512
Edit: Oh the times they are a changing. And so are the hashing algorithms! People are moving from the SHA family of hashing algorithms to Bcrypt, which has several other features like introducing a cost factor to protect against rainbow tables.
i'm not sure if [...] This method is secure enough
No it isn't. Any method of password storage that allows the recovery of a password rather than a secure method of resetting it is not considered to be 'secure' by most. Additionally, how does is the user sent their 'recovered' password? Because using email to do this is just about the worst possible method.
If you cannot get around having to be able to "recover" the password, then what you want is asymmetric [aka public key] encryption. The password would be encrypted by the public key and stored in the database for comparison. The private key should be kept separate, ideally offline on a memory stick in a safe, and protected by at least one password, if not two or more passwords held by separate people.
As others have mentioned this question is better suited to http://security.stackexchange.com than here, but it has already been asked many times, and you will get more strongly-worded encouragements about not doing it this way at all rather than solutions.
Here is your mandatory read: You're Probably Storing Passwords Incorrectly
Now, on the question of how to store ciphered passwords. Don't. Store hashed passwords.
You are probably asking to solve the wrong problem. I suspect you want to create a feature to recover passwords... in that case I'll send you to one of my previous answers if you don't mind.
As an alternative, you may be wanting to store multiple keys for a single user on a client machine. If this is what you want, then your best bet is to secure it with the security the that the operating system offers you. You should not expect to do better than ciphered files for the user provided by means of the operating system.
Otherwise, you basically designing the way over which all of the stored passwords are going to be stolen. Either because what is considered secure now may no longer be considered secure tomorrow, or because we are humans (right?) and we can commit mistakes.
Anyway, your security will be at best as strong as the authentication process of the secondary API (I mean, the one to retrieve the key to decipher the passwords). You do mention Java, what are the chances of your java code being reverse engineered to discover how to get the passwords?
PHP supports SHA1, manual: http://php.net/manual/en/function.sha1.php
if (sha1($str) === 'd0be2dc421be4fcd0172e5afceea3970e2f3d940') {
echo "Would you like a green or red apple?"; }
And JAVA SHA1 example: http://www.herongyang.com/Cryptography/SHA1-Message-Digest-in-Java.html
You can combine SALT + PSK(SHA1) with AES encryption.
I recommended use to SYSTEM SALT (generated SHA512 key on system + SALT on user + PSK SHA512 for login).
Or better use PBKDF2 if you cant use either, bcrypt or scrypt with SHA2.
Related
The current top-voted to this question states:
Another one that's not so much a security issue, although it is security-related, is complete and abject failure to grok the difference between hashing a password and encrypting it. Most commonly found in code where the programmer is trying to provide unsafe "Remind me of my password" functionality.
What exactly is this difference? I was always under the impression that hashing was a form of encryption. What is the unsafe functionality the poster is referring to?
Hashing is a one way function (well, a mapping). It's irreversible, you apply the secure hash algorithm and you cannot get the original string back. The most you can do is to generate what's called "a collision", that is, finding a different string that provides the same hash. Cryptographically secure hash algorithms are designed to prevent the occurrence of collisions. You can attack a secure hash by the use of a rainbow table, which you can counteract by applying a salt to the hash before storing it.
Encrypting is a proper (two way) function. It's reversible, you can decrypt the mangled string to get original string if you have the key.
The unsafe functionality it's referring to is that if you encrypt the passwords, your application has the key stored somewhere and an attacker who gets access to your database (and/or code) can get the original passwords by getting both the key and the encrypted text, whereas with a hash it's impossible.
People usually say that if a cracker owns your database or your code he doesn't need a password, thus the difference is moot. This is naïve, because you still have the duty to protect your users' passwords, mainly because most of them do use the same password over and over again, exposing them to a greater risk by leaking their passwords.
Hashing is a one-way function, meaning that once you hash a password it is very difficult to get the original password back from the hash. Encryption is a two-way function, where it's much easier to get the original text back from the encrypted text.
Plain hashing is easily defeated using a dictionary attack, where an attacker just pre-hashes every word in a dictionary (or every combination of characters up to a certain length), then uses this new dictionary to look up hashed passwords. Using a unique random salt for each hashed password stored makes it much more difficult for an attacker to use this method. They would basically need to create a new unique dictionary for every salt value that you use, slowing down their attack terribly.
It's unsafe to store passwords using an encryption algorithm because if it's easier for the user or the administrator to get the original password back from the encrypted text, it's also easier for an attacker to do the same.
As shown in the above image, if the password is encrypted it is always a hidden secret where someone can extract the plain text password. However when password is hashed, you are relaxed as there is hardly any method of recovering the password from the hash value.
Extracted from Encrypted vs Hashed Passwords - Which is better?
Is encryption good?
Plain text passwords can be encrypted using symmetric encryption algorithms like DES, AES or with any other algorithms and be stored inside the database. At the authentication (confirming the identity with user name and password), application will decrypt the encrypted password stored in database and compare with user provided password for equality. In this type of an password handling approach, even if someone get access to database tables the passwords will not be simply reusable. However there is a bad news in this approach as well. If somehow someone obtain the cryptographic algorithm along with the key used by your application, he/she will be able to view all the user passwords stored in your database by decryption. "This is the best option I got", a software developer may scream, but is there a better way?
Cryptographic hash function (one-way-only)
Yes there is, may be you have missed the point here. Did you notice that there is no requirement to decrypt and compare? If there is one-way-only conversion approach where the password can be converted into some converted-word, but the reverse operation (generation of password from converted-word) is impossible. Now even if someone gets access to the database, there is no way that the passwords be reproduced or extracted using the converted-words. In this approach, there will be hardly anyway that some could know your users' top secret passwords; and this will protect the users using the same password across multiple applications. What algorithms can be used for this approach?
I've always thought that Encryption can be converted both ways, in a way that the end value can bring you to original value and with Hashing you'll not be able to revert from the end result to the original value.
Hashing algorithms are usually cryptographic in nature, but the principal difference is that encryption is reversible through decryption, and hashing is not.
An encryption function typically takes input and produces encrypted output that is the same, or slightly larger size.
A hashing function takes input and produces a typically smaller output, typically of a fixed size as well.
While it isn't possible to take a hashed result and "dehash" it to get back the original input, you can typically brute-force your way to something that produces the same hash.
In other words, if a authentication scheme takes a password, hashes it, and compares it to a hashed version of the requires password, it might not be required that you actually know the original password, only its hash, and you can brute-force your way to something that will match, even if it's a different password.
Hashing functions are typically created to minimize the chance of collisions and make it hard to just calculate something that will produce the same hash as something else.
Hashing:
It is a one-way algorithm and once hashed can not rollback and this is its sweet point against encryption.
Encryption
If we perform encryption, there will a key to do this. If this key will be leaked all of your passwords could be decrypted easily.
On the other hand, even if your database will be hacked or your server admin took data from DB and you used hashed passwords, the hacker will not able to break these hashed passwords. This would actually practically impossible if we use hashing with proper salt and additional security with PBKDF2.
If you want to take a look at how should you write your hash functions, you can visit here.
There are many algorithms to perform hashing.
MD5 - Uses the Message Digest Algorithm 5 (MD5) hash function. The output hash is 128 bits in length. The MD5 algorithm was designed by Ron Rivest in the early 1990s and is not a preferred option today.
SHA1 - Uses Security Hash Algorithm (SHA1) hash published in 1995. The output hash is 160 bits in length. Although most widely used, this is not a preferred option today.
HMACSHA256, HMACSHA384, HMACSHA512 - Use the functions SHA-256, SHA-384, and SHA-512 of the SHA-2 family. SHA-2 was published in 2001. The output hash lengths are 256, 384, and 512 bits, respectively,as the hash functions’ names indicate.
Ideally you should do both.
First Hash the pass password for the one way security. Use a salt for extra security.
Then encrypt the hash to defend against dictionary attacks if your database of password hashes is compromised.
As correct as the other answers may be, in the context that the quote was in, hashing is a tool that may be used in securing information, encryption is a process that takes information and makes it very difficult for unauthorized people to read/use.
Here's one reason you may want to use one over the other - password retrieval.
If you only store a hash of a user's password, you can't offer a 'forgotten password' feature.
I am creating an REST based web application which, after successful user credentials validation, generates auth token and authenticates subsequent requests using this auth token.
The contents(although not fixed yet) of token are
AES_encrypt{username:SHA_256(username,user_specific_salt):timestamp:expiry_period}.
To avoid db call, I am trying to generate salt value based on username itself.
Also, I am not sending salt value to client.
The problem is, I am a bit confused about the solution since the articles I have read so far suggest not to generate salt values on the fly but store at db level. Can someone help me figure out the optimal solution for the above scenario?
It depends on the use-case and level of the security concerns. Having safely stored passwords hashes is of course more important and sensitive than for example authorisations tokens for a web-service of limited functionality.
So the analysis is based on potential risks/benefits of particular solution.
Firstly, look what would happen if you were not using salting at all. Then if someone captures your token and knows its structure (username plus timestamp) may try to recover the key used for the encryption. It is a computational challenging task but in principle possible. Having access to only one or many tokens generated in the same way does not make this task much easier (I may be mistaken, they may be some loop holes in the AES encryption).
The aim is to get your key used for the encryption so that attacker may produce its own valid token for arbitrary user later on.
hacker needs to crack the key
You add a salt, even a fixed one for all the users.
Hacker still has to crack you encryption key, same as before. Once it has it
He takes old token, and updates the timestamp and the job is done. He just copies the original hash. as the timestamp was not hashed useing the salt, so it is not affected.
So lets assume you hash username+salt+timestamp. Otherwise salting is irrelevant as explained above.
So the hacerk needs to crack the salt so it can reproduce the correct hash. Having multiple hashses encoded with the same salt makes it easier to recover the salt. SHA is fast enough to allow brute false attacks nowadays.
hacker needs to crack the key
hacker needs to get one salt from all the hashes
By salting you introduced one extra step for the hacker to deal with but not a difficult one.
You add on the fly generated salt,
Hacker cracks the encryption. Then he needs to crack multiple hashes to recover few salts. He needs to guess the salt generation pattern to fake the token.
hacker needs to crack the key
hacker needs to recover multiple salts from the hashes
hacker needs to deduce the salt generation pattern.
Knowing the pattern it can produce the tokens for any user. Without knowing the pattern it can produced tokens for the cracked users, it is probably enough for the hacker.
Randomly generated salt stored in the DB, one salt for user.
hacker needs to crack the key
hacker needs to recover salt from the hashe
Hacker cannot create tokens for any user, but once knowing the salt it can create token for the hacked user. The DB stored salt does not improved things much, just prevent arbitrary user access but it still allows 'cracked' user access.
Randomly generated salt stored in the DB and changed regularly (hourly, daily).
Now hacking the salt once, does not help in the future, as it will not match the new salt value. Cracking hashes takes longer than hour. So hourly update should be enough. But tricky to implement it correctly, so that the valid tokens would not expire upon salt update.
So depending when you are on the scale of security paranoia and how important is your service you may step up the costs for the hacker.
I would say for your usecase, hashing with salt on the fly is completely fine just do add the timestamp to the messaged hashed, otherwise hashing has no effect.
Now, to prevent your secret key being discovered, you may considering salting our encryption key. That way if the encryption is cracked only for one user not all. But again if it is not banking applicaton, probably not worth it.
I am working on a system that has been hashing user passwords with MD5 (no salt). I want to store the passwords more securely using SHA-512 and a salt.
While this is easy enough to implement for future passwords, I'd like to also retrofit the existing MD5 hashed passwords, preferably without forcing all the users to change their passwords. My idea is to just use SHA-512 and and an appropriate salt to hash the existing MD5 hash. I can either then set some flag in the database that indicates which passwords were hashed from plain text, and which ones were hashed from an MD5 hash. Or I could just try both when authenticating users. Or even just hash new passwords with MD5 and then SHA-512/salt, so they can be treated the same as old passwords.
Programmatically, I don't think this will be a problem, but I don't know enough about encryption/hashing to know if I'm compromising the quality of the hash in any way by applying a SHA-512/salt hash to a password that was already MD5 hashed. My first instinct is that if anything, it would be even stronger, a very light key stretching.
My second instinct is that I don't really know what I'm talking about, so I'd better get advice. Any thoughts?
Function composition with cryptographic primitives is dangerous and should not be done if avoidable. The common solution for your type of problem is to keep both hashes for a migration period, using the new hash where possible and transparently upgrading old passwords (when you check a password and it matches, rehash it with the new algorithm and store it)
This won't work if you have a challenge-response based scheme where you don't get to see the plaintext password, but since you seem to have a stored salt that does not change, I assume your application does the hashing.
If you hash with MD5 first, you will only have the spread of MD5 (128 bit). A large fraction of the space of SHA512 will not be covered by your passwords. So you don't take advantage of SHA512, but it won't be worse than MD5.
You have the benefit that if someone obtains the SHA512 hash and doesn't know the salt (this you have to enforce somehow) can't look up the hashes and get the passwords -- something that would be possible with the MD5 database you have now.
So yes, you can just rehash the existing MD5 passwords. But as explained in the first paragraph, it would be a bad idea to apply MD5 to all new passwords as well and then hash them as SH512. A easy implementation would be to have a boolean 'salted' field in the database next to the hashes (but don't put the salt there).
Trust your second instinct. Use an existing library made especially for hashing passwords instead of trying to cook up your own.
Probably hash your new passwords with MD5 and then hash the MD5 with your password hashing library. That way, you can maintain backwards compatibility with your old passwords.
I.e. password_hash(All old, md5'd passwords) and password_hash( md5(New passwords) )
(Warning: I'm not a cryptography expert)
http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html
If you look at how most Bank and high security people does there password changing. Most of them basically ask people who is using the old encryption method to create a new password. I think you first solution of placing a flag on all existing old MD5 password users, and notify them they need to create new password and slowly migrate them to the new system. That way when you trouble shoot the system if anything goes wrong you won't be asking is this a new user or an old one. Are we double hashing or single? Should never compare two hash as a possible answer because what if MD5('abc') => 123, SHA('NO') => 123, that means someone could have typed in the wrong password but still gets in.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What function to use to hash passwords in MySQL?
Secure password storage
What is the best mechanism for storing passwords into database after encryption of the password? And what is the method of encryption and an implementation in Java?
Never store encrypted passwords. Store a secure one-way hash instead, something like SHA-1 (has some minor security issues), or one of the newer, more secure variants.
Doing so is actually against several regulatory requirements that you may be subject to, such as the PCI DSS if you have any involvement with credit cards (doing any e-commerce?).
Something like http://www.mindrot.org/projects/jBCrypt/ may also prove useful.
+1 for Borealid's comment - even with hashing, the hashing needs to be done properly, and must include "salt" (additional random data to prevent a subset of attacks). jBCrypt will do this for you (as will other similar libraries).
A common way to store passwords is to hash them using a message digest algorithm. I'd recommend SHA1, or if you need more bytes (-> less collision possible), SHA256 or 512. Here's an SHA1 implementation in Java:
http://www.anyexample.com/programming/java/java_simple_class_to_compute_sha_1_hash.xml
It's also advised that you use a salt for making gessing password hashes even harder. Explanation:
http://en.wikipedia.org/wiki/Salt_(cryptography)
I know enough about cryptology to make life difficult for a novice programmer and get laughed at by security experts. So with that in mind, I ask: how secure is javax.crypto.Cipher? I realise that anything can be cracked by someone with a will and a way, but I still would like to know relative details.
The reason I ask is I would like to store account names and passwords that will be sent through my Cryptor class that will encrpyt them, and would like to know if this will do the job. If any one has any literature that I could read, that would be greatly apprieciated.
Thanks ~Aedon
Cipher is a generic class to apply an encryption/decryption algorithm. Its security depends on the actual encryption algorithm used (DES, triple-DES, AES, etc.), on the size of its key, and on the block chaining type that you choose.
If you intend to store passwords securely, then your requirements are quite different from simply "communicating securely/privately". A Cipher on its own is not enough to protect you. You need to use one of these
bcrypt
scrypt
PBKDF2 from PKCS#5
in that circumstance. Here are some arguments and links concerning password security.
The punchline is that "normal" encryption (or hashing, too) is just way too fast to hold off serious attackers. You want to artificially slow down the entire process to make it as hard as possible for somebody systematically attacking your application. A single user won't notice the difference between 1 or 500 milliseconds when entering a password but for an attacker this means that in order to break your scheme it will take them 500 times as long on the average - so if it would have taken roughly 1 month to find a valid password before, now it will take 500 months.
Since NullCipher is a Cipher - not secure at all.