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.
Related
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#
I have an existing client, which calls a server, which in turn calls
https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword
With that, client POSTs to the server (and server, to Firebase) an unhashed password over HTTPS.
I would like to salt/hash the password on the client. I am at liberty to use the same algorithm Firebase uses. But I don't see a method for sending a hashed password to Firebase. And I have existing users who, of course, can't lose access with this migration.
To sign in to Firebase Authentication's email/password provider, you have to send the password in cleartext over a secure connection. There is no way to change this.
This is not a security risk to send the password in cleartext, as the secure connection is end-to-end encrypted, so the only two sides who can see the data can already access it anyway. If somebody can intercept the data and decrypt it, it means they have access to the certificate of your secure connection, which is a much broader security risk.
Of you want to sign in with a password in a different form, the only way to do that is by implementing your own custom provider on top of Firebase Authentication.
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.
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.
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.