I have an issue when it comes to encrypting user passwords. I have a authorization services with which one can create a user account. Given is an email and a password. As for now I encrypt the user password in the server before persisting it in the database.
However I feel that is somewhat wrong because the password is in plaintext when coming in through a https request. So I actually could log the real passwords of users.
Isn't that a dangerous way to handle user passwords? I think it would be better to encrypt user passwords in the client side code (javascript) before submitting a form (either registration or login). So the password will arrive encrypted already.
Am I right with my concerns?
I encrypt the user password in the server before persisting it in the database.
Please don't. Use slow salted hash if possible (BCrypt, SCrypt, Argon2,..)
If you really cannot use the mentioned functions, than a database native hashing functionality is better than encryption.
https://practice-code.github.io/architecture/how-to-store-passwords-in-a-secure-way/
the password is in plaintext when coming in through a https request
Nope, the https encrypts traffic between the client (browser) and the server.
Yes you can see the password in the browser side before encryption (but the user entered the password, so it looks ok to access its own data) and the server needs to validate the password anyway.
Isn't that a dangerous way to handle user passwords?
Indeed. So maybe it's a good idea to offload the user authentication to already proven services (AWS Cognito, IBM AppID, Azure AD,..) or to social accounts (Google, FB,..)
I think it would be better to encrypt user passwords in the client side code
As already commented, that is not helping at all. Then the encrypted value becomes the password
Nothing is in clear text when using HTTPS, data is encrypted that is the main point of using server certificate !
As an alternative approach usually one stores the password hash in db instead of the password text, so eventually your code uses hash algorithm to generate the password hash and compare it versus one stored in DB, by that even if someone was able to access the database records ,that one is unable to figure out what is the password because all he gets is the hash value
Using Hash in C#
Related
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.
Is it safe to send a bcrypt encrypted username and password through a http post? I basically just want to set a server up for my friends with a username and password that is encrypted so they can access stuff on my server.
It's just about as dangerous as doing all communication in plaintext without the safety net of SSL/TLS. There's not much benefit.
If you care about security, make sure all usernames and passwords are encrypted over the wire by using a common standard like SSL/TLS. There have been a number of vulnerabilities in this approach lately (e.g. OpenSSL), so it's worth investigating ways to establish secure communication channels. OWASP is a great resource for web application security strategies.
Bcrypt isn't for encrypting communications, but it is a cryptographic hash function that's particularly good for password hashing.
What does the server need to know when deciding whether to accept or reject a login attempt? It has to decide whether the username and password provided by the client are correct. Interestingly, you can do that by storing a derivative of the password that difficult to reverse rather than the password itself. The benefit? If somebody gains access to your password database, your user's passwords should still be secure. That's not to say you should publish your password database, but it's better to engineer everything as though that could happen.
When we log in to a website like Gmail we give our password , Now Gmail is a Https website hence during transit, the password cannot be sniffed by Man in the middle attack ,If there is a SSL MITM ,then the password is seen in cleartext.
Is there a mechanism ,which encrypts the password during log in i.e even after SSL MITM the attacker would only get the encrypted password.
This would be client side functionality using javascripts , right?
But again the client can choose to prevent or modify the scripts.
Or is there any other mechanism?
You could hash your username and password at the browser/server and then compare hashes at the business layer. This will prevent MITM attacks and allow the BO to validate credentials.
You could use Javascript, but then you (1) have to get the Javascript safely to the user and (2) exchange keys to do the encryption.
While there is some value in protecting the password, if the SSL session is compromised the MITM can hijack the session and all the data, or prompt the user to change their password and just collect it.
You could use OpenId, but then you only move the problem of authentication to the OpenId server. You still need a way to get the user's secret to the server.
So, generally, clear-text passwords over SSL to establish a new, authenticated, session cookie is the way to go. Anything else reduces down to your orignal shared secret problem or the web browser not having anything but SSL to work with.
This question is not language specific. I'm curious how to properly send username and password from a website login form to a server.
My guess is to hash the password, put username/password in the POST body and send it over HTTPS. What's a better way?
For good measure I'll mention a less than ideal method:
http://www.somesite.com/login?un=myplaintextusername&pw=myplaintextpassword
The important parts are that you transmit the form data in the POST body (that way it's not cached anywhere, nor normally stored in any logfiles) and use HTTPS (that way, if you have a good SSL/TLS certificate, nobody can sniff out the password from observing your network traffic). If you do that, there is no big extra benefit in hashing the password, at least not during the transmission.
Why do people talk about hashing passwords, then? Because normally you don't want to store the user's password in plaintext form in your server-side database (otherwise the impact of a compromised server is even worse than it would be otherwise). Instead, you usually store a salted/hashed form, and then apply the same salt/hash to the password received via the form data, so that you can compare the two.
For more information on salting, see http://en.wikipedia.org/wiki/Salt_(cryptography) (and the links there).
If you're using HTTPS, then you can send the name and password in a POST body which will be secure from eavesdroppers (assuming you trust SSL). You don't need to hash the password, if you do then the password hash is just as useful as the password itself, so it doesn't buy you anything.
A more important question is how you store the password on the server side. Storing a hashed password is only acceptable if you use a good algorithm such as scrypt. But that's still not as good as an advanced protocol such as SRP.
You should always use HTTPS and avoid homebrewed code. SSL will take care of hashing & encryption. That is the ONLY secure method.
Also ensure you're hashing passwords on the server end and storing the hash, not the original password. Then compare the hashes to check logins. This will prevent attackers reading plaintext passwords straight out of your db if its compromised.
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.