From a security point of view does it make any difference where an encrypted password is stored for logging in? I was thinking of having something like the following:
Password = 123456
Encrypted = 21909qujea8je2829dj92
url = selectaccount.aspx?p=21909qujea8je2829dj92&email=someemail#somewhere.com
or
Session["encryptedPassword"] = 21909qujea8je2829dj92
Session["LoginEmail] = someemail#somewhere.com
There's no need to store the password in either of these locations. Once the user has authenticated, their cookie should maintain their identity. The modern built-in asp.net implementations of authentication are secure and flexible. What reason do you have to re-invent the wheel?
PS - Hashing instead of encryption is considered best practice for dealing with passwords.
Keep it on server (in session) and dont make it public via querystring. Once a user has entered his password it should not be sent back to him (encrypted or not) so that he can carry it to the next page.
Related
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 am building a simple web application.
I don't have the ability of using SSL to secure the communication with the client.
Right now the flow is:
First time the user is registering:
1) The user is choosing a user and a password (HTML form)
2) The password is being hashed by a hash function and a key (with concatenated salt) (jQuery)
3) The hash result is being sent to the server and stored in the DB
In any login:
1) In the welcome page - The password is being hashed and the result is being sent to the server
and being compered with the hash result from the the DB.
2) If the password is correct' a authentication token is being sent to the client and being
stored in a cookie.
3) In every page the token is sent to the server and being validated.
** My Questions are: **
1) Is my way of encrypting the data is good or is it lack (comparing it to SSL)?
2) How can I prevent XSS (cross site scripting) - steeling the token from the user cookie and using to to retrieve data from the server without supplying user and password?
Is my way of encrypting the data is good or is it lack (comparing it to SSL)?
No. The hashed password is effectively the real password and is sent in the clear.
How can I prevent XSS (cross site scripting) - steeling the token from the user cookie and using to to retrieve data from the server without supplying user and password?
With the usual mechanisms for protecting your site against XSS, i.e. sanitising / escaping all the data you output so scripts can't be injected from clients.
I've a code to persist information in cookies about users like UserName and password.
Question is:
Its not secure to store information like that plain text in cookies.My DB store hashed passwords,so i could save those hashs in cookies and retrieve them later,but if i do that i wouldnt be able to fill password's textbox cause the hash string would be too long for it.
Is there any solutions?
You never should store Passwords in plain text, and even a hashed password can be vulnerable to reverse-lookup unless it is salted correctly. ASP.NET Forms Authentication already lets you create a Persistent authentication cookie that will allow the user to stay logged in, so you should use that instead. See the Timeout, expires, and IsPersistant properties when Creating the Forms Authentication Cookies.
Alternatively you could setup a token based authentication system, by which users get a security token after they enter their login information and this token is valid for a specified amount of time. This is how Live ID and Google Accounts work, and they usually store the tolken in a cookie that is valid for weeks at a time.
What's the best way to save user credentials in flex? Local storage doesn't seem like good place for storing confidential data, because it saves information as a plain text.
You shouldn't. Use browser cookies or a session token to identify the user to the server. For instance:
User enters username and password into a form in Flex and clicks login.
Server validates credentials. Then either in memory or in a database the server associates a random (and sufficiently secure) token with the user. Then the server returns the token to the client.
Client saves the token in either a cookie, LocalSharedObject, or just in memory. Then subsequent requests also include the token.
You can use ExternalInterface to communicate with JavaScript and store data in browser cookies.
Don't store users' name or password in cookies - create a session in the server with credentials in it, and store the session id in the browser cookies.
if your service don't support credential, then the only think you can do is save user login state in SharedObject.
You can save hash value of UserName + Random Token to SharedObject and save a copy of UserName too in SharedObject, then when application created creationComplete check wheather the hash value match with the saved user name.
the good thing about this trick is:
Password never persisted locally.
Harder to fake login because need to
match username with the hash value.
a bit hard to explain here you can check it here, source code is available for download.
User credentials are normally stored in a session variable.
You don't necessarily need to save the credentials as plain text in Local Storage; in fact, Local Storage (SharedObject) is actually serialized as AMF, so it's not plain text to begin with. Whatever medium you use to store your sensitive data, you should certainly consider using some sort of hashing or encryption techniques like SHA1 or RSA.
The difference between hashing and encryption is this:
Hashing (SHA1, MD5, etc) is a one-way encryption - in other words, it's very difficult to determine the original value of the hashed value, so what you can do is compare one hashed value to another since these hashing algorithms will always spit out the same thing.
Encryption (RSA, AES, etc) is a two-way encryption - in other words, you can determine the original value of the encrypted data, usually by using a public/private key combination
It really depends on what you're trying to do.
Hope you come right
SharedObject is a very bad place to store your password in.
Please see this:
http://livedocs.adobe.com/flex/3/html/help.html?content=security2_22.html
I want to make a login system using ASP.NET (MVC).
On the internet, I found some bad examples that involved SQL in Click events. Other information pointed to the ASP.NET built-in membership provider.
However, I want to roll my own. I don't want to use the built-in membership provider, as it only seems to work on MS SQL, and I don't like the idea of having a few foreign tables in my database.
I could probably think of something, but I need a few pointers in the right direction. It does not have to be high-security, but just regular common-sense security.
And I have a few direct questions:
A lot of systems seem to have the Session ID stored in a user table. I guess this is to tie a session to a user to prevent hijacking. Do check this every time a user enters a page? And what do I do if the session expires?
Hashing, salting, what does it do? I know of MD5 hashing and I have used it before. But not salting.
Best practices for cookies?
I dont know about best practices but I can tell you what I do. Its not hitech security but it does the job.
I use forms authentication. I receive the password secured with ssl via a textbox on the login page. I take that password and hash it. (Hashing is like one way encryption, you can get hash code that cant be reversed back to the password). I take that hash and compare it to the users hash in the database. If the hash's match i use asp.nets built in authentication handling, which handles cookies for me.
The FormsAuthentication class has methods available to do this fo you, such as SetAuthCookie and RedirectFromLogin. they will set the cookie and mark them as authenticated. The cookie asp.net uses is encrypted. I cant speak for its security level though, but its in fairly common use.
In my class i do the password check and use formsauth to handle the rest:
if(SecurityHelper.LoginUser(txtUsername.Text, txtPassword.Text))
{
FormsAuthentication.RedirectFromLoginPage(txtUsername.Text, true);
}
You can implement your own membership provider using the ASP.NET infrastructure, see MSDN docs for MemberShipProvider class.
The built in provider works well. It does actually work with MySQL, although I found it not to be as straight forward as the MS SQL version. If you can use then do, it'll save you hours of work.
If you need to use another data store then I concur with axel_c, if I was going to roll my own then I'd write a membership provider as per MS specification. It will make the code more maintainable for any developers following you.
Salting is the practice of adding a unqiue string of characters to whatever is being hashed. Suppose mySalt = abc123 and my password is passwd. In PHP, I would use hashResult = md5(mySalt + password).
Suppose the string is intercepted. You try to match the string, but you end up matching gibberish because the password was salted before encrypted. Just remember that whatever you use for salt must be continuous throughout the application. If you salt the password before storage, you must compare the hashed, salted password to the DB.
You can use the built in SQL membership provider - and you could set up a dedicated "user access" database if you don't want the .Net membership tables within your database - just specify that in the connection string.
THe advantage with the provider model is at the application level, the code is independent of what particular authentication store you have used.
There are a good series of tutirials on the asp.net site:
link text
A disadvantage of the Membership Provider by microsoft is that you can't use it in a domain driven approach. If you want to, you can create your own user object with your own password hash and still use the authentication cookies provided by Microsoft. Using these authentication cookies means that you don't have to manage the session IDs yourself.
public void SignIn(User user)
{
FormsAuthentication.SignOut();
var ticket = new FormsAuthenticationTicket(1, user.UserName, DateTime.Now.AddMinutes(30), expires, alse, null);
var encryptedTicket = FormsAuthentication.Encrypt(ticket);
var authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket)
{
Expires = ticket.Expiration
};
httpContextProvider.GetCurrentHttpContext().Response.Cookies.Add(authCookie);
}
public void SignOut()
{
FormsAuthentication.SignOut();
}
I use my own user object and tables.
I store my passwords hashed in the usertable with a unique salt per user.
This is secure, easy to implement and it will fit in your design.
Your database table won't be polluted by Microsofts membership provider crap.
I would avoid the whole issue and use openid. There is a library available that you can use directly.
Here is a link to a blog post about putting this in place