I want to store username and password in cookies.
I encrypted password by using MD5 Hashing technique.
so how can i store that encrypted password in cookies??
Thats not the way. You put some parameters such as timestamp, user agent, current ip, username, etc. But not the Password. Now compute hash for your token and send it as a cookie. Thats how an authentication token is made.
For authenticating the user on Log in, compute the hash on your server and compare it with the one in DB. Don't ever send your hashed password on line. For better criteria you should use salted hash for passwords. See this to get to know about salts.
Moreover MD5 is hashing not an encryption. There is a lot of difference between both of them. Also, use SHA instead of MD5. See this for details.
You shouldn't store username and password in the cookies because that's sent to the client. Even if it's hashed, specially if you are going to compare the hashed password received in the cookie with the one in the database directly. That breaks the purpose of hashing.
If you want to mantain the session of the user between requests, you should use the session ID. I'm not a C# expert, but with a quick google I've found this:
HttpContext.Current.Session.SessionID
That's what I would store in the cookie.
I would not recommend this to anyone...
Rather save get the passwords from the user. save them in a session to use through out the users connection period and if you want the user to use that same password and login later you will have to have a database that you store the data in.
So to store the information as follow
Session["username"] = txtusername.Text;
then to use it again on a different page or somewhere else
string username = Session["username"].toString();
Related
I have a web-based-tool. On the login-form, the password will hashed before sending it.
All fine, the database stores only hashed passwords.
Now, we want a login with LDAP over DirectoryEntry.
But the constructor only accepts plain passwords.
My question: How can I pass hashed passwords to DirectoryEntry-class?
Current method:
public bool isAuthenticated(string domain, string username, string pwd)
{
string domainAndUsername = domain + #"\" + username;
DirectoryEntry entry = new DirectoryEntry(_path, domainAndUsername, pwd);
try
{
Object obj = entry.NativeObject;
return true;
}
catch
{
return false;
}
}
I do not know C#, but as far as LDAP protocol goes, there is no way to authenticate with an already hashed password.
Why do you need to hash the password before transmitting it?
If it is to avoid transmitting it over the network, the easiest solution to use would be to connect to the LDAP directory over SSL.
As a side note, IMO, transmitting the hashed password is less secure than the clear one :
If the attacker intercept the request, he will be able to authenticate with the data he found either way
If the attacker succeed in dumping the database and retrieve the hashed password, if all he needs to do is to transmit that to authenticate, it renders the fact to store hashed the password useless
Edit : Additionnal information
I don't know which LDAP directory you use, but on OpenLDAP, you could implement this kind of mechanism if you don't use the bind operation (for example, you won't be able to use the password policy overlay).
You can implement a SASL Proxy Authorization to :
connect to the directory with a technical account
search and retrieve the entry user which tries to login
test on the custom hashed password attribute if the hashed provided is the stored one
rebind with another technical account with a proxy authorization to act as this user
It will allows you to still benefit from the ACL mechanism and logging system for users operations performed
BUT: This will be available only on OpenLDAP (or if another LDAP implemenation offer the same mechanism) and it is not really the most state of the art about the LDAP protocol ;)
I created a custom registration page in asp.net c# and encrypted the password and saved it in SQL express database.I want to decrypt that password when user logins.I am using build in Login Control??
Can you please guide me how i will decrypt that password??
In code behind of login control i have used a select query with where clause that matches the
user password that is stored in encrypted form in database.
You should match the encrypted password and not decrypt all of your passwords. You should temporarly encrypt the password the user inserted and query the database searching for a correspondence with the encrypted password.
An alternative to what #trippino recommended would be to store the hash value of your passwords in your databases, instead of the encrypted version. When the user logs in, you create a hash of the user's password and compare it with the hashes you have stored in your database.
This is usually safer since at no instance (other than the initial hashing phase) you are dealing with the actual user's password.
You don't decrypt the password. You simply match the encrypted password using the same algorithm you used to store it.
the easiest way to do this job is to encrypt the password that is entered and match it with already saved password. like e.g. you entered a password 'test' at the time of registration and in database, it's saved as '193ed271e1eytjgwedguwegdkgwke', now when user enter a test again on login encypt it with same function and it'll again generate the same encrypted code, if it's not the same code, it must be not the same password !
I have implemented an md5 hash salted algorithm.
Using this algorithm I have saved the hashed password and salt value to the database.
then on login page retrieved the salt value of login user, get the byte of password add the salt value and computed hash and matched the result with the saved password and it is working perfectly but I am still able to see my password value in clear text at client side.
How can I encrypt the password value at client side along with md5 hash salted algorithm?
You do it right way. You won't be able hash password on client-side without knowing salt (and passing salts to client is not a good idea). If you want that data sent by client was secure, use ssl.
Note: If you use ssl client will still be able to see my password value in clear text because data will be encrypted only before sending.
You can use data protection API (DPAPI) to store password on the client side securely. Use SafeString class, to store password in memory and, as #PLB already mentioned, use encrypted connection.
If you are worry for password which you are typing in text box.
Then change TextMode of textbox as Password
Like this
<asp:TextBox ID="txtPassword" runat="server" TextMode="Password"></asp:TextBox>
There are many different ways to solve this, the easiest I can come up with right now is to use some kind of challenge; the server sends a value the client has to use as a salt. The server ensures that the value is unique, hasn't expired, and only used once (this makes sure a replay attack isn't possible.)
This makes sure that a plain text password isn't sent, only a hashed one. The server can trust (trust as much as when doing plain text auth anyway) the client to not simply resend some old hash since the clear text password is needed to compute the hash with the "one-time-salt".
Another, more sophisticated (and secure) way is to generate a RSA-keypair from the password where the server has the public key, and the client the private. The client also has a copy of the servers public key. The user enters the password, and only the correct password will get the correct rsa-key.
The user then encrypts the requests with the server's public key, and then signs the requests with the user's private key. Only the server can then decrypt the requests, and the server can verify that the sender really is the right user by verifying the sign with the user's public key. And the opposite for the response. To add some security you should add some unique "salt" as I wrote earlier to ensure replay attacks are impossible.
Hi I think I may have done this the wrong way round can anyone help explain how you hash/salt a password. Do you do it from the client or the webservice?
I have a datacontract which has a password datamember, in my service I do this to create a hash/salt of the password before it is saved:
So here is the process in which I was thinking.
Rest Service has https for secure connection
User creates account (along with password)
//to stop packet sniffing when user creates account https is used during POST so no one can see the password?
web service then creates a hash of the password to store it
//so if anyone did get access to the service/database they couldnt make much use of the data in terms of breaching accounts
Then some means to authenticate that user there after
Is this correct?
Sounds like you're on the right track. Hashing along with the salt value should never occur on client side, as attackers will have access to that code. And https would indeed secure the connection, disallowing others from reading the data.
During authentication you do the same thing: take the password the user entered via https, hash/salt that value, then compare the result hash with the value in the database. And of course if you ever return a Student object to the client, it should contain neither of the values.
It may be wise not to reuse the Password property of Student since now you can't tell whether it contains the plain password or the hashed value.
I know it is not best practice to store a password in a cookie, even if the data is encrypted.
However, I have a web application that needs to be able to search against Active Directory and, as far as I can tell, it requires that the user first binds using their credentials. This means that for each search request, I need to pass the user name and password to the DirectoryEntry constructor.
Given these constraints, is there an alternaive to storing the password in a (secure) cookie?
In absence of something better (e.g. getting a service account), the solution that I'm contemplating is either to store the credentials in an encrypted cookie or cache the DirectorySearcher object.
Thanks
You could store the credentials server-side, generate a unique identifier for them, and store this identifier in a cookie. You can make the identifier expire if needed.
Store the password in a Session Variable, this variable will expires if alive beyond the SessionTimeOut period.