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.
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.
First of all, I am sorry for my bad English.
I am writing an app with a backend, which I want to make safe. I am using HTTPS for the connection, but a lot of people say that this is not enough protection.
At the moment, my user credentials are sent to the server via JSON format as plain text, which isn't a good way, I guess. At the server, my password is hashed with a random salt and stored in the database.
If the login is successful, an authentication token is generated and sent to the client. The client is using it as a header.
Do I need to do more? I read something about digest access authentication. Should I implement this authentication method, or is there a better way to make my login safe? Or is this the right place to use this authentication method?
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
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