I'm searching for a specific way to encrypt my data.
I want to encrypt it with my password and decrypt it with that.
Later I want to gain other people access to chosen parts of my data with their passwords.
Is there any other way than to decrypt the data everytime I add a new "reader" and encrypt it all again with a "mix" of all passwords?
And than the big question is how to decrypt without knowing the passwords of everyone?
And than I thought of another problem. How to validate that the given/login password is correct?
I thought the following might work without saving the actual password or the encryption password:
Get a password ; "Thats an amazingly bad password"
Use the hash as encryption and decryption key ; hash(salt + "Thats an amazingly bad password")
Save the hashed hash as validation for the password ; hash(hash(salt + "Thats an amazingly bad password"))
What do you think about it?
Thanks for help everyone
Encrypt the data once with a secure key such as random bytes.
For each user encrypt the above key using the user's password (properly extended), save that in a file or DB under the userID and a salted/hashed password for authentication.
To access lookup the user's entry verify the supplied password with the salted/hashed password, decrypt the data key with the user's password.
Decrypt the data with the data key and return to the user.
Side advantage: A user's password can be changed without changing the actual key the data is encrypted with.
For the second part:
Do not hash(hash(salt + "Thats an amazingly bad password")), use a password extension method such as PBKDF2 on the user supplied password for the encryption key. Such methods take a salt and a password and iterate many times to make the operation slow, somewhere around 100ms seems to be a good target.
Hashing a hash does not accomplish anything other than adding a trivial amount of time to the operation.
Related
I browse but didn't got proper solution.i am working on asp.net membership all i want to do is to retrieve user password when user apply for forgot password for condition 1. i want password to be in encrypted format in database and 2. retrieve password in decrypted format.is it possible.
Normally, encrypted passwords would be stored using a one way hash. This means
that the password cannot be decrypted once it is stored. Many authentication systems
work by taking the password ( of the user trying to authenticate ), encrypting
it using the same one way hash function as was used to store the password in the
database, and then doing a string comparison in order to determine if the
resulting encrypted password matches the one that exists in the database.
How are you determining if the user requesting the password is actually
the owner of the account ? Perhaps you can clarify your question with details
of the environment so that we may offer alternative solutions.
Use PasswordRecoveryControl
But anyhow it's not advisable to send password in plain text format.
I want to encrypt user's personal data then save them in database .
the encryption must be done in application ( I can't do that in sql server side )
now I wonder if it's possible to use each user's password to encrypt and later decrypt their data ? what are pros and cons of this approach /
One big 'con': what if the user changes his/her password? Then you would need to re-encrypt all data!
You've said that you want to store secure personal data of a user. Doing this unless the personal info. is extremely sensitive is generally NOT recommended for a number of reasons. What is commonly done however is hashing + salting of the user's password.
This page has a good explanation on how hashing and salting works and why it's better than encrypting, and then decrypting the password.
http://net.tutsplus.com/tutorials/php/understanding-hash-functions-and-keeping-passwords-safe/
As for encrypting the user's personal information, just like a password we can use a custom salt + hashing algorithm that's quite simple but effective on our application to use the custom hash equivalent of the userID which is expected to be permanent, static and persistent forever.
Since the uID (or a specialized unique string for every user) can be hidden from normal public and we ensure that our custom shared function cannot be accessed from unauthorized sources, we have a solid secured system.
This means, we hash+salt personal info based on a unique string such as a userID and a hash+salt the user's password aswell. For the personal information to be decrypted, both the userID hash and password hash should match with the database.
A better approach would just be to use known encryption protocols within your program. Data sent via HTTPS TLS for example is quite secure if implemented right.
I need to encrypt content in my web application on a per-user basis.
I, the root user, do not want to have access to users' content, period.
How can I make it so users are the only ones with access to their content? Perhaps I can make it so a hash of their login password acts as an encryption and decryption key (then their password is stored one-way hashed in my database, and the encryption/decryption hash is generated from their raw password on login and stored in a local cookie)? But what if they change their password? Then I have to update all their content which could take a lot of processing power.
Is there an encryption method that would provide this, without having to re-encrypt their content if their password changes? Something similar to ecryptfs on Linux, perhaps? Is researching ecryptfs a good place to start?
Is making it so only the user can access their content on my servers (and not even me) even feasible?
Process:
Generate a random secret to encrypt their content.
Using their provided password encrypt the random secret from #1.
Store their password as a one-way hash (with salt, maybe multi-hash).
Upon Password change:
Re-generate the value from step #2.
Re-generate the hash-cache from step #3.
Upon Login:
Hash password and check against hash generated in step #3.
If password matches - use actual provided password to decrypt random secret from #2.
Use random secret from #2 to unlock data encrypted in #1.
Notes:
No one can decode the data without knowing the random secret (#1). Random secret can only be unlocked with user's actual password (#2) (short of brute-force). User's actual password is only known in one-way hashed form (#3) so you can confirm it's the same, but cannot decode it and recover #2.
A forgotten password process is not possible (you can regenerate #3, but random key in #2 is now lost as is everything locked in their vault).
You don't have to re-encrypt everything in step #1 every time they change their password, only the (simple/quick) random secret from #2.
If you cache their provided password, or the random secret generated at step 1, or their (decrypted) content anywhere you could cause data leaks.
You're spot on that you need to use their password as a key.
I wouldn't monkey with ecryptfs because an encrypted file system isn't the best solution. You wouldn't want one user's data to be encrypted with the same key that another user used.
When you encrypt the data, you should generate a random string to use as salt. This prevents someone from using a pre-generated list of hashes to decrypt your data. It also changes the hash of two people who might use the same password.
When a user changes their password, you'll have to re-encrypt the data and generate a new salt value. This is the level of security I would expect as a customer, knowing that when I change my password, I'm re-encrypting all of my data to prevent someone from trying to brute force my key.
You can store the salt value in your database unencrypted.
I'm using ASP.NET membership for a site that will serve primarily sophisticated users. I understand the difference between hashed and encrypted passwords, and I'm trying to decide between the two.
After my last client complained bitterly about hashed passwords being a total PITA, I've started to favor encrypted passwords. But someone suggested this just isn't secure enough.
So my question is: What, exactly are the risks of encrypting passwords? Any person with the ability to steal passwords by decrypting them from the database would surely have the ability to reset them if they were hashed, no? I'm having trouble seeing where someone could cause trouble with encrypted passwords but couldn't with hashed ones. Making it convenient for users is also important.
The risk with decryptable passwords is that people use the one password for various logins and accounts, not just for the application you are dealing with.
With an encrypted password, a
stolen/decrypted password could be
tried out on users' other accounts (e.g. a stolen banking password could lead to access to their email).
With a hashed password, there is no
recovery. Theft of password hashes
should never easily yield usable
passwords
Treat passwords as the property of the account owner. It's not yours to view, decrypt, or do other things with. If a user forgets their password, offer reset, and not retrieval.
The point is that Encrypted passwords can be decrypted...so it is possible that with having access to the keys etc all the passwords could be known.
Hashed (with salt) passwords are a 1 one function so there is effectively no possible way of determining what the password was which means the user supplying the password has less to worry about. Sure someone could change the hash in where ever it is stored (e.g. database) so that user could no longer log on, but the password they had provided originally still wouldn't be known.
Edit
As you've tagged the question ASP.Net, I'd recommend using BCrypt.Net library to generate your hashes
The risk is, that encrypted passwords can be decrypted to get the plain text password.
Hashes normally can't be reversed.
Reversing an MD5 Hash
A quite common occurance is people using the same username and password on all their internet sites.
All it takes is one site password to be decrypted, and all the users sites are at risk.
While with a hash, the cracker never gets the plain text password.
As other users have said, encrypted passwords can be decrypted and are not a good idea.
If you use a standard hash technique the user who has access to your database could put in the standard md5 for "password" for example. You can solve this issue with a salted hash which takes the input string and a salt string value to create a unique hash that can not easily be replicated. Store it somewhere safe and use sha1($salt . $input). You now have a salted hash.
Can users request that their password be emailed to themselves if the password is stored as a hash value?
Is there any way to convert a hash value to the clear text value with the proper information (& what information would you need)?
If a user has the same password hash value stored on two sites, would their password be the same for both sites?
If you're only storing a hash of the password, then no. ...and you should only be storing a properly-salted hash of their password, anyway.
Password reset mechanisms are the proper alternative.
Hashed passwords cannot be retrieved in general (this depends on the hashing function, secure hashes cannot be retrieved). If they have the same hash on two sites, they could have the same password, this depends on the hash salt used by the sites, what method etc.
If your password is securely stored in a good hashing system, a provider should never be able to email you your password, you must reset your password if you forget it.
In short, no. With most hashing algorithms, you can have multiple inputs with the same output. It is often better to offer a password reset option.
There are different types of hashing algorithms. Some are more secure than others. MD5 is a popular, but insecure one. The SHA-family is another more secure set of algorithms.
By definition, a hash is a one way function. It can not be reversed.
http://en.wikipedia.org/wiki/Sha-1
If there was a simple way to recover the clear-text password, there would be no point in hashing the passwords to begin with. At that point you might as well just base64 or ROT13 them. (don't do that!)
As others mentioned, use other password recovery methods. There really is never a good reason to have access to clear-text passwords.
If the hash at two sites is the same, the user most likely has the same password at both. Not 100% guaranteed however, there could be a hash collision, but that is hugely improbable.
There is no way to reverse the commonly used hashes. They can be bruteforced (trying every single possible password) or you can use a wordlist (using a list of commonly used passwords) in combination to brute force to speed it up some, but it is still a very slow and CPU intensive process.
The best way, which many sites use, it to create a "Password Reset" button where you enter your username and email, and if they match, it sends you a random password and gives you a link to the login page and you can login with your random password and change your password.
To do this you must have a model with the fields:
Hashed_password
Salt
And you need to know the method user to hash the password( Here I use SHA1)
Then you can define in your controller:
def self.encrypted_password(password, salt)
string_to_hash = password + "wibble" + salt
Digest::SHA1.hexdigest(string_to_hash)
end
Next you can compare:
user.Hashed_password == encrypted_password(password, user.salt)
True means that "password" is the password for the user "user"
The general idea behind storing a hash of a password is to ensure the passwords are secure...even from those who have access to the database. Trust is never implicit. A hash is a one-way algorithm, so there is no way to derive the original password from a hashcode. Usually, when a user needs to recover their password that was stored as a hash, you should ask them their secret question, and either email them their temporary password, or email them a temporary link where they can change their password. This ensures that the password is never stored clear text, and is secure from all prying eyes, even those who might be assumed to be trustworthy.