Related
I am trying to add unique salt to the hashed passwords in MySQL database. What is the most legitimate way of doing this? I am aware of that I need to hash them again to add a salt. These passwords are used for the website login. I can add one particular salt to each password before the code (written in C#) sends the user info to the database. In such a case, the login will work if I salt the passwords in MYSQL with the same salt. I know that it is not the most secure way. How do I implement the same with unique salts for each?
As the comments above state, you cannot reverse a hash, so you can't get the original password back to apply salt. You could apply salt to the hash string and hash again, but then you'd be stuck with that weird double-hash authentication method forever. Be sure to comment your code to explain why it is implemented this way, because programmers who take over your code when you leave will be confused.
I'll tell you how I did it when I was working on an app that needed to update its password-storage code from using MD5() to using salt + SHA1().
Leave the old hashed passwords alone.
Add a new column to the table storing your passwords for the new format of password. Call it password2 or something like that. This column is NULL by default.
Change the code to check the new column. If it is not NULL, then authenticate the user's input using the new hash method against what is stored in the database.
If the new column is NULL, then check against the old password using the old authentication method. I.e. hash the user's input and check that hash against what is stored in the database. Once you know the input is correct, hash the input again using the new method (add salt and hash the input, or better yet, use Bcrypt or Argon2 which contains its own salt in the hash result) and store that result in the new column.
Also set the old column to NULL after the new hash format is stored in the new column.
Of course the password-change code and new account creation code will also need to be changed. It should ignore the old password column, leaving it NULL, and only store passwords in the new format in the new column.
Once all users have logged in at least once, the old password column should be NULL on all rows. You can remove the application code that supported the old password hash format, and then drop the old password column.
But there will almost surely be some stragglers who don't log in regularly, so after a few weeks of waiting, I would just proceed to drop the old password. Those users who haven't logged in recently will be forced to do a password reset.
The advantage to this method is that it works totally seamlessly for nearly all your users, and inconveniences only a few (and some of those users may never return anyway).
The disadvantage is that it takes a few weeks to wait for everyone to log in once. If you need the change to occur immediately, then you may have to force all the users to do password reset.
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 10 years ago.
I am working on a project that has to have authentication (username and password)
It also connects to a database, so I figured I would store the username and password there. However, it seems like not such a good idea to have passwords as just a text field in a table sitting on the database.
I'm using C# and connecting to a 2008 express server. Can anyone suggest (with as many examples as possible) what the best way to store this type of data would be?
P.S I am open to the idea that this info not be stored in the database if a good reason can be provided
You are correct that storing the password in a plain-text field is a horrible idea. However, as far as location goes, for most of the cases you're going to encounter (and I honestly can't think of any counter-examples) storing the representation of a password in the database is the proper thing to do. By representation I mean that you want to hash the password using a salt (which should be different for every user) and a secure 1-way algorithm and store that, throwing away the original password. Then, when you want to verify a password, you hash the value (using the same hashing algorithm and salt) and compare it to the hashed value in the database.
So, while it is a good thing you are thinking about this and it is a good question, this is actually a duplicate of these questions (at least):
How to best store user information and user login and password
Best practices for storing database passwords
Salting Your Password: Best Practices?
Is it ever ok to store password in plain text in a php variable or php constant?
To clarify a bit further on the salting bit, the danger with simply hashing a password and storing that is that if a trespasser gets a hold of your database, they can still use what are known as rainbow tables to be able to "decrypt" the password (at least those that show up in the rainbow table). To get around this, developers add a salt to passwords which, when properly done, makes rainbow attacks simply infeasible to do. Do note that a common misconception is to simply add the same unique and long string to all passwords; while this is not horrible, it is best to add unique salts to every password. Read this for more.
Background
You never ... really ... need to know the user's password. You just want to verify an incoming user knows the password for an account.
Hash It:
Store user passwords hashed (one-way encryption) via a strong hash function.
A search for "c# encrypt passwords" gives a load of examples.
See the online SHA1 hash creator for an idea of what a hash function produces (But don't use SHA1 as a hash function, use something stronger such as SHA256).
Now, a hashed passwords means that you (and database thieves) shouldn't be able to reverse that hash back into the original password.
How to use it:
But, you say, how do I use this mashed up password stored in the database?
When the user logs in, they'll hand you the username and the password (in its original text)
You just use the same hash code to hash that typed-in password to get the stored version.
So, compare the two hashed passwords (database hash for username and the typed-in & hashed password). You can tell if "what they typed in" matched "what the original user entered for their password" by comparing their hashes.
Extra credit:
Question: If I had your database, then couldn't I just take a cracker like John the Ripper and start making hashes until I find matches to your stored, hashed passwords?
(since users pick short, dictionary words anyway ... it should be easy)
Answer: Yes ... yes they can.
So, you should 'salt' your passwords.
See the Wikipedia article on salt
See "How to hash data with salt" C# example (archived)
As a key-hardened salted hash, using a secure algorithm such as sha-512.
The best security practice is not to store the password at all (not even encrypted), but to store the salted hash (with a unique salt per password) of the encrypted password.
That way it is (practically) impossible to retrieve a plaintext password.
I'd thoroughly recommend reading the articles Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes [dead link, copy at the Internet Archive] and How To Safely Store A Password.
Lots of coders, myself included, think they understand security and hashing. Sadly most of us just don't.
I may be slightly off-topic as you did mention the need for a username and password, and my understanding of the issue is admitedly not the best but is OpenID something worth considering?
If you use OpenID then you don't end up storing any credentials at all if I understand the technology correctly and users can use credentials that they already have, avoiding the need to create a new identity that is specific to your application.
It may not be suitable if the application in question is purely for internal use though
RPX provides a nice easy way to intergrate OpenID support into an application.
In your scenario, you can have a look at asp.net membership, it is good practice to store user's password as hashed string in the database. you can authenticate the user by comparing the hashed incoming password with the one stored in the database.
Everything has been built for this purposes, check out asp.net membership
I would MD5/SHA1 the password if you don't need to be able to reverse the hash. When users login, you can just encrypt the password given and compare it to the hash. Hash collisions are nearly impossible in this case, unless someone gains access to the database and sees a hash they already have a collision for.
Im making a program in C# that has passwords and I need to encrypt them. So far I flip the string backwards (so hello becomes olleh) and then I use a loop that loops through each character, and the loop inside it loops through another string that has the converted letters to see if they match. Using this, hello = Ghh#$ so it works fine. So anyway, are there any extra stuff I can add to it? PS what is salting and how is hashing one way?
Rule one of cryptography is don't write your own encryption scheme. Instead use a library such as http://www.cryptlib.com/why-use-cryptlib-10-good-reasons which has bindings for C#.
For more information check out the first answer to:
https://security.stackexchange.com/questions/2202/lessons-learned-and-misconceptions-regarding-encryption-and-cryptology
First off, the difference between encryption and hashing is, at a high level, that encrypted data can be decrypted with the right key, whereas hashed data cannot be retrieved except via brute force methods like pregeneration or rainbow tables.
Hashed passwords are validated by hashing the user's input each time that they log in in the same way that you do when they create the account, and comparing the result of the hash. For any given input, the hashed result should be the same.
Obligatory rant:
There is a good argument to be made that passwords should always be hashed using a cryptographically-strong algorithm. You may hear the excuse that "my application/web page/etc is not all that important, there is no sensitive information there", or "I'm just learning so it isn't important", but the fact is that if I can crack the security of one website, or you leave your machine logged in and I steal your password file from your "educational" app, I can take all of the user's email addresses and virtually guarantee that at least a few of them will use the same password for that gmail or yahoo account. I can then send reset requests for just about any site that their email tells me they have an account for and get access to those also. So it is very important that no matter what software you are writing, if it stores passwords, you should do the responsible thing and salt + hash them properly.
Salt: http://en.wikipedia.org/wiki/Salt_(cryptography)
Hashing: http://en.wikipedia.org/wiki/Cryptographic_hash_function
Simplistic Example:
var salt = "abc123";
var encryptedPassword = HashingAlgorithm("password");
var encryptedSaltedPassword = HashingAlgorithm ("password" + salt);
Console.Writeline(encryptedPassword);
Console.Writeline(encryptedSaltedPassword);
writes out
aIdekXieklKq309nasdf
dfk#cxk)8lkdfesijcde
The point of salting your code is to prevent dictionary attacks. If anyone figures out your HashingAlgorithm, they can brute-force run through every word in the dictionary and figure out that "password" hashes to be "aIdekXieklKq309nasdf". If you salt your to-be-encrypted words, they'd have to know your salt word too.
Also, it's good to hash your passwords into a database instead of using some two-way algorithm, that way anyone (including you and your co-workers) having access to the database can look and see what your users use as passwords (since a lot of users tend to reuse the same passwords on multiple sites).
I am about to make a 'Log In' for my app and was wondering what is the best way to encrypt a password for my user that i will enter in my database ? I found many way on Google but don't know which is the best.
I would go with a one way salted hash.
Using a SHA1 hash for example, you would have a way to store the password as a hash which cannot be reversed back to the original password. Then when the user enters his/her password you perform the same SHA1 hash on the password and compare that hash with what you have stored in the DB, if they match then the password is correct.
To further secure the hashing, you can add a salt, this is essentially a randomly generated value that you generate for each user then you create the account, and store the salt value in the user record. When you create the hash of the password, you first combine the password with the salt and hash this combined value. To authenticate the user you combine the entered password with the salt stored for the user, perform the hash on the combined value and compare.
By adding the salt to the mix, you ensure that the hash for passwords that happend to be the same have a different hash because the salted portion differs. So if two users have the same password "Password1234", the stored hash for the two will not be the same so it cannot be determined that two users have the same password.
I recommend using Rfc2898DeriveBytes
It uses a good standardized Key-Derivation-Function, and modern hashes. You need to pass in a salt in addition to the password to prevent rainbow-tables. And it mixes salt and password for you, so you don't need to figure out how to do that yourself.
Use bcrypt. No, really, drop whatever ideas you have of building your own method, and use bcrypt. The world has enough homebrew insecure password hashing schemes already.
Storing salted password hashes, with per-user salts of course, is all well and good. But salting only prevents rainbow table attacks, it doesn't prevent bruteforcing. So, paradoxically, you don't want to use a fast method to generate or verify the password hashes. MD5, SHA, whatever - they're all fast. Repeat after me: use bcrypt.
You can use RSA Algorithm: http://www.codeproject.com/KB/security/RSACryptoPad.aspx
Use Cryptography algorithm provided by .net framework
normally , many application uses MD5 algorithem
See here
I want my application to save the password encrypted in a database or in a text file.
How can I do that assuming that the database or text file can be open by anyone?
Duplicate
Encrypting/Hashing plain text passwords in database
Not duplicate
I'm asking for code specific for .NET
EDIT: I'm saving the password for later use. I need to decode it and use it to login.
It doesn't have to be super secure, it just needs to be unreadable to the human eye, and difficult to decode with a trivial script.
StackOverflow readers don't know how to write secure password schemes and neither do you. If you're going to do that, save time by sticking with plain text. From Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes:
Rainbow tables are easy to beat. For
each password, generate a random
number (a nonce). Hash the password
with the nonce, and store both the
hash and the nonce. The server has
enough information to verify passwords
(the nonce is stored in the clear).
But even with a small random value,
say, 16 bits, rainbow tables are
infeasible: there are now 65,536
“variants” of each hash, and instead
of 300 billion rainbow table entries,
you need quadrillions. The nonce in
this scheme is called a “salt”.
Cool, huh? Yeah, and Unix crypt —-
almost the lowest common denominator
in security systems —- has had this
feature since 1976. If this is news to
you, you shouldn’t be designing
password systems. Use someone else’s
good one.
Use BCrypt - Strong Password Hashing for .NET and Mono. It's a single cleanly written .cs file that will continue to meet your needs as password cracking computers get faster.
BCrypt - Strong Password Hashing for .NET and Mono
Triple DES is one way to do it, as long as you mean "A password that my system needs to be able to recall in order to access a resource". If you mean the password is something a user needs to be able to gain access to your system, probably don't want encryption, just a hash will do. When you store the hashed password value, it is useless to anyone with direct database access, but can still be used for authentication. All you do is compare the stored hash against a hash of the incoming password. If they match, then you grant access.
It isn't perfect, by any means, but it is the way 99.999% of people store their passwords.
If you want to argue that you wish to provide the password back to a user if they lose/forget it, then please don't. Issue them with a temporary password (which you store hashed in the db) and get them to change it on first login.
Use Data Protection API either with the user or machine store (e.g. different key per account your program/database server runs under vs. one key per machine). This will help you decode the passwords later and you don't have to remember or store any encryption keys. The downside of it is that when you reinstall the system/delete the account you won't be able to recover the data, I believe.
If you use encryption for securely storing passwords, you'll need to store the encryption "key" somewhere, too. This will be the "weak link", since if someone gets hold of the encryption key, they will be able to decrypt the encrypted passwords.
Since this is passwords that we're talking about here, a much better solution is to use a one-way hash. You hash the password when the user first creates it (preferably hashing with a salt value) and store the resulting hash value. Since hashes are one-way, no one can reverse the hash to the original plain text value.
To check that a users password is correct, you simply ask the user for the plain-text password, hash their input again and compare the resulting hash value with the hash value you have stored (taking salts into account of course). If the two hash values are the same, the user has entered the correct password.
Please see the following links for further info:
Hashing Password with Salt
For encryption (if you need to use that), I'd use Rijndael (AES).
Based on your question I can see two approaches depending on why you are storing the password.
A. if you only need to authenticate using their password and nothing else.
In that case, going using an algorithm that is not reversible (Hashing) would be your best choice. You will need to make sure of a couple of things:
Make sure that the connection is encrypted when transmitting the password from the client to the server. This will prevent it from being sniffed out. This is pretty trivial to do with web applications since the web server is doing the heavy lifting for you. If not it gets a lot tricker and is the subject of an whole other question.
Choose a solid hashing algorithm to prevent collision. I would recommend SHA-256 even if it does provide a larger result than SHA1 or MD5. The reference from Microsoft on using their implementation of the algorythm is here.
Salt the password to prevent attacks using rainbowtable (i.e. looking up the password in large table with the precomputed hash and the associated password in clear text). The answer here (sited in your question) gives good pseudo code in Python on how to do it. There is also a good example of .NET code here.
B. if you need to be able to read the password for each user for other purposes than authenticating the user.
This case is easy if we are only talking about storing a password (or any kind of sensitive information) on a single computer (server). If that's the case, using the Microsoft Data Protection API would be a good solution since it is tied to that computer and (depending on the way you work) the user under which you application runs and takes care of the worst of the job for you (creating, storing, and using keys). You can find some code reference from Microsoft here. If you need it on more than one system and are not willing to enter the password on each system you install on your application then things get a lot more complex because you need to implement a lot of it from scratch. That would be the subject for another question I would think.
If you need to decrypt the password for later use and it doesn't have to be SUPER secure, then use the method here:
http://support.microsoft.com/kb/307010
It's well documented, and easy to understand.
do you need to encrypt it ever again? otherwise use a hashfunction to encrypt it and encrypt the password given by the user with the same hashfunction and look if the hashes are equal.
The reason for not using a 2-way-encryption is that one cannot decrypt your key - since a good hashfunction has collisions.
Personally, I would use something that has one-way encryption - MD5, SHA1, etc...
You can use the FormsAuthentication class with it's HashPasswordForStoringInConfigFile method. When validating the user, encrypt the entered password and compare it with the stored version.
Like ocdecio I would use TripleDes, I would also save the salt in the database too. The key for me is usually hard coded, but the salt should change for each encrypted item.
If you just need the password for an internal authentication process, you should not save the actual password, but save a hash of this password. When you need to check if a password is valid, you'll have to run the hash function on provided password and compare it with the hash you stored in your database/file. You can never find the original password from the hash.
If you need to keep the original password, you'll have to encrypt it. You can use for example a public key infrastructure if you have a process that writes the passwords (public key) and another one that reads them (private key).
Do you really need to be able to retrieve the password itself? If you're storing a password for the purposes of authenticating someone (or something), you should rather hash it (with salting) and then compare that hash to the hash of the password supplied by the party wishing to be authenticated.
If, on the other hand, you need to store the password in order to be able to retrieve it and supply it to some other authentication service later, then you might want to store it encrypted. In that case, use any decent symmetrical encryption algorithm you can, such as TripleDES or AES or Blowfish.
Briefly:
Get a big random number which you will keep private and only your application code will have access to.
Encrypt the password + random number with an ancryption algorithm like SHA1, most programming languages have a cryptography framework.
Store the hashed password.
Later when you want to check inputted passwords, you can rehash the user input and compare to the "virtually" undecipherable stored passwords.
Here's a string encryption article with example code .NET
http://www.devarticles.com/c/a/VB.Net/String-Encryption-With-Visual-Basic-.NET/3/
There is no need to use anything fancy, because anyone with a little bit of skill and determination will break it anyway.