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.
Related
I am a beginner of asp.net. I currently have a login page with forgot password link button on the bottom of the screen. I am also using forms authentication to prevent an unauthorized user from accessing the other pages. The authentication seems to be working fine except for one thing.
How do I retrieve my password from the user list?
You don't want to store or retrieve the original password for security reasons - asp.net should be storing a hash of the original password in your data store. When a user enters their password again, the configured hashing algorithm should hash it to the same value as before and it matches the stored hash on the backend to authenticate.
See also Asp.net MVC - How to hash password for more background.
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.
I'm implementing my own OAuth authentication system (with refresh_token support) for an app and I have some questions about how to do it:
Client identification: The client is registered in the auth server and gets a client_id and a client_secret. How do I generate it? is there some kind of relation between both values?.
User authentication: The client sends the users_credentials (username+password for example) + client_id and gets a refresh_token and (temp?)access_token. That access_token is the one I should use in further request or I should use a accesss_token`=F(refresh_token,access_token,client_secret). In the second case what does the F function consist on?
Access token refresh: The client send client_id, refresh_token and gets a access_token (and a optional new refresh_token). Does the access_token need the same conversion (whatever it be), as in the point 2?
If I'm wrong, when and how is the client_secret used?
Complete answers and concrete examples will be "bountied".
The authorisation/authentication server generates these values when you create an account with them (for instance when you create a developer account with Facebook or Google). If you are doing these parts yourself, they should be cryptographically secure pseudo-random numbers or letters. Remember that the client ID is usually publically visible, so choose a reasonably large set of alpha-numerics (I use 30 characters). The secret is private and can be harder to guess so I chose 30 digits with letters, numbers and symbols. These are not related to each other, it is just that one is public and the other isn't.
The usual way this works is that there is a browser redirect to the auth server passing the client id in the URL (and redirect uri) and specifically NOT the user id and password. The whole point of OAuth2 is that the client system never sees the user name and password, only the auth server. After this redirect, the auth server verifies the client id, checks the username/password (for instance) and then returns to the redirect uri with a temporary code. This temporary code is passed back to the Auth server in order to obtain an access token. Since this call is made as a POST from the server, it also passes the client secret to verify that it really is the correct client system and not someone who stole the client id from somewhere else. At this point, the auth server will return an access token (and optional refresh token - you do not need to use them, I don't).
If the client system wants to log the user in without them having to type in their username and password all the time, it can use a refresh token, if available, to call back onto the Auth server and if the Auth server is happy that the refresh token is still valid and any other business rules are correct, it can give you back another access token directly without the user being involved.
I recommend reading the OAuth2 spec here: OAuth2 Spec RFC6749. It can take a while but if you delete the bits you don't need and reduce the amount of data, there are plenty of useful examples in it.
FIRSTLY, The client identifier can be any string that you want, but it should be unique for each client. It can even be the client's choice if you wish.
The client secret should be a cryptographically strong random string. Here is how you could generate one in C#:
RandomNumberGenerator cryptoRandomDataGenerator = new RNGCryptoServiceProvider();
byte[] buffer = new byte[length];
cryptoRandomDataGenerator.GetBytes(buffer);
string uniq = Convert.ToBase64String(buffer);
return uniq;
SECONDLY, The whole point of OAuth is to allow external apps to do things on your behalf without asking for your credentials. So, you need to implement an authentication server that does the logging in part for you. The user opens the app and gets an option to Log in using your website. You tend out access tokens and refresh tokens once the user has keyed in his credentials. The app can then simply use the tokens to perform actions on the user's behalf. I wrote an answer to How would an efficient OAuth2.0 server / provider work? that explains how access tokens can be constructed.
Remember, the need for refresh tokens and the lifetime of access tokens purely depends on how you intend to use them and what does your security framework look like.
LASTLY, The refresh token can also be an HMAC encoded string/a JSON object as I had explained in the answer to the linked question. You can have random refresh tokens and a large backend storage to keep it to verify the tokens in the incoming requests, or have HMAC encoded strings for added security/less storage requirements/latency to decrypt/encrypt tokens.
Also, do make sure that you go through all the flows and possibly the RFC too as mentioned by Lukos.
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