I'm wondering how to encrypt my password column in SQL Server 2008. I've read this article, but I still have no idea how... is there an easier to understand tutorial? Thanks!
The usual practice is to store a hash of the password. Like:
HASHBYTES('SHA1', convert(varbinary(32), #password))
With a hash, you can verify if the password matches, but you don't know the password itself. So even if a hacker gains complete access to your database, he still does not know the passwords.
There are many tutorials on the web.
You should instead consider storing hashes of passwords instead of using encryption. In case you are unaware of the differences, a hash (also called a one way hash) takes an input and produces gobbledygook (called a hash) such that for the same input the same gobbledygook is produced. Authentication works by hashing what the user entered on the client and comparing it to the gobbledygook in the db. If they match, the passwords are the same. Without getting into specifics, hashes can never be reverted back to plain text which is their protection. Encryption however involves creating a cypher such that if you have the decryption key you can revert the cypher back to plain text.
If you are using SQL Server and ASP.NET, you should look into Forms Authentication with the SqlMembershipProvider.
Explained: Forms Authentication in ASP.NET 2.0
SqlMembershipProvider Class
An Overview of Forms Authentication
Microsoft have made this super-easy with the snappily named
FormsAuthentication.HashPasswordForStoringInConfigFile.
http://www.adventuresindevelopment.com/2009/05/23/a-simple-way-to-hash-passwords-in-aspnet/
Related
We have a legacy application that is storing the user's passwords down in the database unencrypted. We've had a fair few customers come onboard now which encrypting this password is a big deal to them (fair enough). Currently it's just a Nvarchar(100) field inside an SQL Server database table.
The situation is that we have multiple client applications accessing this database and validating against this password.
Just wanting to get advice on how we can achieve encryption on this field in the database without having to rewrite all the client applications that read off of it? It's not out of the question to change the client applications but we're trying to get away with this with as little fuss as possible.
Any ideas?
Do not do that, store salted, iterated HMACs of the passwords. Use something like Bcrypt, password_hash, PBKDF2 or similar.
If the HMAC is not salted and iterated it is not sufficient. Simply hashing without salting leaves the hashed passwords open to rainbow table attacks.
Convert the existing passwords now.
This has puzzled me for a while now. I don't have a broad understanding on encryption, but I understand the principle.
For the sake of an example, let's assume I have a program whose sole purpose is to post a random user's input to my private facebook profile. Now to do this, the program must have my login information to facebook (if this is not the case, assume another third-party application). This information, or credentials, must be stored somewhere, since the program's post method would be done without administration.
I know it is a bad policy to store the login credentials in the code as plain strings, as the compiled code can be decompiled and my credentials would be readable. The recommended solution is to store them in a separate file, encrypted.
As far as I understand, the encryption / decryption needs a key that also needs to be stored somewhere. Can't this key and the encryption algorithm be read from the decompiled code and used to decrypt the credentials?
Is the benefit of storing the credentials encrypted based on the extra step on decompile-decrypt, or have I drastically misunderstood something?
There are 2 ways one could check supplied credentials when you have encrypted version:
Decrypt the encrypted version; this would obviously require storing the tools necessary to decryption, which is unsafe
Encrypt what you are trying to check, and see if it matches your encrypted version. This does not require the ability to decrypt anything.
I need to view users password history in an ASP.net application.
Is there any way to achieve it?
You have to maintain that as an encrypted string in your backend. Meaning in the database or some file system (not recommended).
It depends.
In fact, storing plain passwords is the worst approach in terms of security.
Administrator must not have access to plain passwords, this the reason of most of applications prompts you to create a new one, because passwords are hashed and hashing prevents from reverting to plain text.
If you need to track passwords, you'll need to write a custom membership provider tracking them.
There is nothing built into .Net that will provide this information. You would have to write your own solution to create an audit trail of passwords but this would involve storing passwords in a visible format. Remember the massive caveat about plain passwords though!
So long as you're only doing this for old passwords i.e. storing them AFTER the user has set a new password it should be ok.
I often make small websites and use the built in ASP.NET membership functionality in a SQL Server database, using the default "hashing" password storage method.
I'm wondering if there's a way to authenticate a user by hashing his password on the client and not sending it in clear text over the wire without using SSL.
I realize that this would only be applicable for users with Javascript enabled.
Or... possibly, this would be a great built-in capability for Silverlight (is this in the Silverlight roadmap?)
EDIT:
I'm also looking for "degrees of security." Meaning, if there is a method that has some advantages over simply sending plaintext password, I'd like to know what they are and why.
I know there are lots of people who do small sites with logins (such as a family website or volunteering to make a site for a local cooking club) and don't see the need for purchasing SSL certificates.
This is possible. This is actually what Kerberos authentication does, only with a little bit of added spice. To ensure that your authentication mechanism is secure, you need the following:
A common hashing algorithm on both the client and server.
A one-time salt value generated on the server and shared with the client.
The original password stored in a database.
To securely authenticate a user via hash code, so you avoid sending the actual password across the wire, first generate a random, single-use salt value on the server. Send this salt value to the client, and generate a hash code from the salted version of the password the user has input. Send the resulting hash code to the server, and compare it with a hash code generated from the salted version of the stored password. If the comparison fails, discard the salt, regenerate a new salt value, and repeat the process.
The reason for the single-use salt is to prevent anyone listening to the conversation from capturing the hash code of the users password, which, when you use hash code comparison, is just as good as having the password itself.
Note that you need to keep the original password around, you can't hash it once on the server and save the hash in the database. If you need to ensure that the passwords stored in your database are also secure, then you will need to encrypt them before storing them. I believe that ASP.NET membership providers do allow you to store passwords encrypted, however, if you really wish to have a secure authentication mechanism that is difficult for a hacker to crack, then I would recommend handling password storage and retrieval entirely on your own.
Finally, I should note, that such a complex password transfer mechanism should be largely unnecessary if you use SSL to encrypt your connection during authentication.
References (for those who have never heard of Kerberos or SRP):
http://en.wikipedia.org/wiki/Kerberos_(protocol)
http://en.wikipedia.org/wiki/Secure_remote_password_protocol
This is a bad idea, security wise. If you send a non-ssl form that contains the hashed password, then anyone capturing traffic has all they need to login. Your javascript has to result in something that indicates success (a redirect, token passed to the server, etc). Whatever it is, the listener now can recreate that without proper authentication.
SSL was built for a reason, by people who tried a lot of other web authentication schemes. It is far safer and cheaper to get a cert than to try write your own safe authentication scheme that works without encryption.
Added for clarity:
Client side hashing alone is not safe. Say I have a form with the following inputs
<form action="signin.whatever" method="post">
<input type="text" id="txtUser">
<input type="text" id="txtPass">
<input type="hidden" id="hiddenHash">
<input type="submit" onclick="hashAndSubmit()">
</form>
where hashAndSubmit() hashes the password and puts it in hiddenHash, and blanks out the password field. If I sniff your submission and see the following fields:
txtUser:joeuser
txtPass:
hiddenHash:xxx345yz // hash result
that's all I need as an attacker. I build a form with your user and hash value and I'm all set. The password is not necessary for a replay attack.
To get around this, you have to look at one-time salt values, or other schemes. All of which introduce more cost(don't forget developer time) and risk than SSL. Before you do something like this, ask one question...
Do I trust myself more than years and years of public testing of the SSL encryption?
You could do this, but it would be just as insecure. The problem is that someone could capture the hash and replay it (just as they could the original password). I suppose you're providing some protection against the exposure of the actual password (in case they use it on other systems), but your system will be no more secure.
You can implement your hashing algorithm client side (in javascript) and send only the user name and hash result over the wire. Note that in order for this to be secure the hash must be salted with a string provided by the server, and the string must be unique for every request. The sever still needs to check whether the hash is correct or not and authenticate the session.
At least you have to use a salt for generating the hash. Otherwise the hash value is as "valuable" as the plain password when intercepted - at least on your site.
You can send as post fields the username/realm/password hash following the HTTP Digest protocol. AFAIK there is no built-in client component nor server side component to generate/validate this so you have to do everything manually. It also requires your storage to store a specific hash format, see Storing password in tables and Digest authentication
The advantage is that you're following a well analyzed and understood authentication protocol. Don't roll your own.
Asp.net stores the session in a cookie, thus not having to worry about sessions on the server side (traditionally sessions are stored in a database, and lookups are done via a session ID, which is usually a Guid like string).
In my previous question, I was asking about how a spring application stores/creates sessions etc: Spring authentication, does it use encrypted cookies?
Cletus pointed out that storing a username/id in a cookie, although encrypted, is a security issue because the would-be-hacker has both the encrypted text, but also the hacker knows what the actual encrypted text is i.e. the userId or username.
What are you thoughts on this?
I am sure StackOverflow is also using this mechanism, as is **99.9% of asp.net web applications that are using formsauthentication in this manner.
Microsoft's MSDN site itself is filled with examples like:
FormsAuthentication.RedirectFromLoginPage(UsernameTextbox.Text, NotPublicCheckBox.Checked);
In the above code, the username value is stored in the encrypted cookie.
actually, I recall that the asp.net website was hacked because the web.config didn't have the Protection=All in the forms authentication tag.
So is this a real issue?
To repeat what cletus linked to:
In case you're wondering what a "crib" is. see: http://www.faqs.org/faqs/cryptography-faq/part03/
Cryptanalytic methods include what is
known as practical cryptanalysis'':
the enemy doesn't have to just stare
at your ciphertext until he figures
out the plaintext. For instance, he
might assumecribs''---stretches of
probable plaintext. If the crib is
correct then he might be able to
deduce the key and then decipher the
rest of the message. Or he might
exploit ``isologs''---the same
plaintext enciphered in several
cryptosystems or several keys. Thus he
might obtain solutions even when
cryptanalytic theory says he doesn't
have a chance.**
Maybe you should take a look into this document: Improving Web Application Security: Threats and Countermeasures -- Threat Modeling
It's a good start point to understand what security risks are involved and how can you mitigate that threats.