I want to make my ASP.Net site authentication seamless using Ajax call.
So I consider using client side authentication service of microsoft that should be used via HTTPS because it sends username and password in plain-text format.
And the problem is that I can't use SSL in my site.
So I found a way to hash data before passing to web service that is described here
but the problem is there is a salt in DB that should passed to client for creating hashed password (that equals to DB saved password). and this is not safe.
Is there a better way for doing that?
I found a way.
We will use RSA for encrypting username ans password.
in summery I'll have a web service that creates RSA keypair and save it (this key will be regenerated every day to be more secure).
I will have a textbox or hidden field that calls this service and get the public key.
the for encrypt username and password with jCryption library client side and pass this to my authentication service using ajax call.
so the server will decrypt them with private key and the authenticate user.
I found a way.
Check this out: Secure AJAX Authentication without SSL
Just in case you were looking for an ASP.NET version of jCryption for bi-directional communication, which you mentioned you tried, you can find one on GitHub here: jCryptionNET
Related
We are implementing JWT to allow our client side to authenticate through our separate authentication server.
The client posts the username and password to the authentication server, receives a JWT and then logs in to the main site with the JWT.
Clearly, the token includes the username and some other non-secret information.
The question is if to use JWT to pass secret information and how.
Here are a few options that might be considered:
Don't do it. Have the main website server call a back-end API with the authenticated username to get the information it needs.
Pass the information as Private claims encrypting the values with a symmetric encryption and sharing the key/pass-phrase between the main website and the authentication server.
Encrypt the entire token.
Are there any best practices here? what are the ups and downs of these options?
You shouldn't use JWT for passing secret information.
These tokens are usually signed to protect against manipulation (not encrypted) so the data in the claims can be easily decoded and read.
If you need to pass sensitive information please look at JSON Web Encryption(JWE)
You should check JSON Web Encryption for this purpose
So I have a web Api that authenticates users by username and password. The clients talking to the API will android phones that have an internal app on it to get / send some data from / too the api.
I have hashed passwords in the database with a salt. The connection between the client and the API will be SSL.
Now on the website (MVC) I log users in by generating a new hash and matching this against the hash in the database.
The some of the android devices will have a config file that locks the app to a specific user. Now I rather not store the password in plain text on the device and would like to encrypt the password.
The question now is what would be the best practise here on comparing the hashed password. I dont think its save to just send the plain password to the API or is it?
It's safe, because you're using SSL.
Basic authentication isn't acceptable for plain-text requests, but since HTTPS encrypts everything, it shouldn't be an issue.
Storing the password is a completely separate concern, as you've noted, and that should be encrypted as well, which it sounds like you'll have Android do for you. The only consideration is that you will have to do a reversible encryption to be able to send up the password itself to your API.
Basically:
(client-side) User enters creds
(client-side) Encrypt creds, store in configuration
(client-side) Read from config, decrypt creds
(client-side) File HTTPS request to API with Basic authentication type, using decrypted creds
(server-side) Hash (one-way encrypt, basically) the password, compare against database
That sounds like exactly what you've got, and I see no problem with it.
That all said, just for what it's worth, I'd be tempted to implement an OAuth 2.0 server for this particular use-case, so you don't have to think about persisting the password at all. That's a pretty big undertaking (sort of--it doesn't take too long with those instructions), and you should evaluate it on a case-by-case basis. But any time I have to worry about API authentication, I generally wind up either going with that, or wishing I had.
I would consider using something like JWT (JSON Web Token, http://jwt.io). You can have a client authenticate against your API, and if they provide the right credentials you can issue a token to them, which they can persist on local storage. They would then provide this token in the header of any API requests that require authentication. You can use OWIN middleware to intercept requests, check/validate the token and let the requests through to your controllers if you consider the token to be valid.
Suppose I have a login web form like the following:
UserId: testuser
Password: ThisIsStrongPwd
[LOGIN] (button)
Now, all I want to do is encrypt the password (using an industry-accepted secure measure) when the user clicks the [LOGIN] button.
I know that SSL will encrypt the entire POST, right?
The steps will be something like:
User types id and password.
User clicks [LOGIN] button Info is posted securely to web server. --- How?
Server-side checks the pwd the user posted against the (hashed) one in the database.
Server returns to user their default.aspx page or index.htm page or whatever on an UNencrypted (non-SSL) URL.
There is no need for the rest of the session to be encrypted -- and possibly slow.
How would you do this using ASP.NET for example? or ASP.NET MVC?
..all I want to do is encrypt the password (using an industry-accepted secure measure) ..
For your use case, SSL is the only industry-accepted secure measure. There are ways to encrypt and send a form data from the browser without requiring ssl, such as jCryption. But they are not a replacement for SSL. read this Javascript Cryptography Considered Harmful
SSL is used to encrypt the transport layer, it's not a tool to encrypt specific values. All requests and responses for the page is encrypted, which is the point of having the page secure.
You can only send data securely from a page that is secure. If you would only encrypt data one way, you would be sending the data from an unsecure page. Someone could have intercepted the page and added code to it that steals the password before it's encrypted.
This is not possible in an application where you will accept users you (the server) do not otherwise know. The foundational problem you have is the requirement to share a secret that will enable you to encrypt and decrypt information that no one else can read.
Without a process to negotiate that secret, you cannot communicate securely. Negotiating that secret is one of the key features of SSL/TLS.
It will likely be useful to read up on the history and implementation of TLS to understand why it is necessary to have a fully secure channel. You may also be interested to learn about session jacking, a mechanism by which a third-party can "steal" a login token that is exposed outside of an SSL session.
How to Encrypt Client side login before sending to server ?
You should use HTTPS.
Building security by yourself is hard, and you are very likely to get it wrong.
You should stick with the systems that the experts use.
On the server, remember to hash and salt the passwords, preferably using bcrypt.
There's one very simple solution. SSL. Ensure that all your login activities are served via https:// URLs.
The way that you do this, at least the "setting the server up" part vary depending on what web server you're using. You'd be better off asking a question of that nature on http://www.serverfault.com/
You can only use https - any client side encryption would be viewable on the client and therefore useless. There is SO question on this: password encryption at client side
You should really use HTTPS, but if you can't use HTTPS then the alternative is to create a hash.
Server generates a random 'salt' for the session
JavaScript on client-side creates a cryptographically secure hash of the user's password and the salt.
Hash is sent to the server, you can then retrieve the password from the database, create a hash using the salt for the session and the password from the DB and check if it is the same as the one sent from the client. - If it is then the password is a match.
An example of using JavaScript to protect passwords: http://pajhome.org.uk/crypt/md5/auth.html
I have a service (WCF) with which my ASP.NET page will communicate. The WCF service has hashed passwords in its data store (a file actually). The WCF service requires the username and the hashed password on every call.
Nowm the problem I'm encountering is that if I authenticate the user with forms authentication in ASP.NET, a cookie will be saved in the user's computer after the user is authenticated but I would like to save the username and hashed password too so that the user may able to use the WCF service. Where should this information should be saved so that it is safe and secure?
Should I use session variables? If I choose that option that, then should I switch from forms-based authentication and manually authenticate using session variables or use both forms-based autentication for web page access and store the username and hashed password in a session variable? What are the pros and cons of each?
Can you store the username and password (hashed of course) in another cookie? Each time you communicate, grab the cookie and send it along with the username to the WCF service.
On the WCF service end you'll have the username and the hashed username/password combo. If you apply the same hashing you should end up with the same string that you've got stored in the WCF end, if they match the user is valid.
Regards to your edit:
Not sure that there is a much of a distinction between them as you're suggestion. If you use forms authentication a session variable is created and (assuming you're using cookies) a cookie is stored that allows the session variable to be associated with the user. So even if use forms authentication you're still using session variables.
The only question really is if you want to store a hashed version of the password entered by the user in a session/cookie. The pro is that its being stored somewhere and that could potentially pose a security risk.
A completely alternative approach is rather than sending the password and re-authentication upon each request, send an authentication token that doesn't relate to the user's password. Validate this token instead.
The token could be issued upon successful login, and should use the same hashing algorithm as the WCF. Send the username and token as part of the request and validate that it is valid, authorised and still current.
Definitely not on the client side (cookies). Use the cookie to authenticate the user to ASP and for the session ID. This is the ASP.NET default. Than store the username and PW in the session.
Consider using Windows Authentication or other recommended mechanisms, since they will bring more security.
#your edit: I suggest keep using forms authentication along with related controls (or any other preimplemented method in ASP.NET). Reimplementing it on your own would make large effords for no reason - at least if you want to get the same safety as the .NET authentication brings. It really is more than comparing hashed passwords..! Also, use the session, since this is the natural place to store any additional user related data. Again - sessions are easily configured and relatively safe.