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?
Related
For an Angular 5 application, I am hitting a login web API with the credentials. I am sending the user credentials in request (POST) body. The credentials which I sent is clearly visible in browser form data. How can we hide the credentials while sending to API?
Form Data in Browser(image)
I think there's basically two ways to treat credentials in a secure way (and it's not angular dependant):
The whole connection is end-to-end encrypted, i.e. using https as transfer protocol, making use of SSL to encrypt the data. I think you would still see the value in your console, but no-one else should be able to detect.
You don't store / send the password itself, but an anonymized version of it. I.e., you would store the hash of a password in a database, and as of that, you would also hash the value entered in the password field and submit that one.
So, I would conclude it's less an issue in terms of your angular (frontend) design, but more of the overall (security) architecture of the application middleware.
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.
We use SAML through Okta to control access to our API. We have a way to get Paw to set the cookie needed via an endpoint on our server sending our username and password. This works great, we just hit that endpoint once before and we are good to go.
The issue comes from having to store the password in Paw in the session POST body. We would like to share our paw files but it would be risky to have to remember to clear the password each time.
Is there a better approach to this? Maybe a way generate an ask user prompt?
I am using angularjs on the client side and WEB API on the server side (C#).
I'm trying to implement Authentication and Authorization mechanizm,
I understand that session state is a "bad" practice for web api, so I read some more options, but somethings were unclear to me, or perhaps someone could suggest me a better solution, I would appreciate it.
after user logged in successfully, generate a token for him, and send it in the first response back to the client. the token will be added to any authorized request after that. the question is, how the server could tell what user is that? use DB to store data like username, and system role id, with the token as key?
after user logged in succesfully, encrypt or something like that important data like 'username;system_role;other_info' and send it back as a token?
perhaps use encrypted 'FormsAuthenticationTicket' of asp.net? like here?
I'm sorry for the long, and maybe too ease question, but I really couldn't understand from the web what is the 'best practice' for my case, and it is the first time that I don't use session for authentication.
thanks.
and thank all of you for viewing this question.
I am not sure to on how do this so i am asking for the community help on this matter.
I read int his post Can you help me understand this? "Common REST Mistakes: Sessions are irrelevant" that sessions are not "completely" advised on the REST convention, and that all authentication should be made using HTTP Basic authentication or Digest.
Ok, so far i get it.
But has far has i know, basic authentication is made on the actual server against a regular non-encrypted text file.
Would it be going against the convention, putting the username/password in the http request parameters, instead of passing them down trough the headers and letting the web server do the authentication?
This way, for every request made, the user/pass parameters would be checked and managed using my own logic. I mean using a database table, that has all the info necessary for the application.
The method I currently use is the first request is for a auth token via a POST method, which contains Headers of Username and Password, these are then verified against my authentication methods. If the credentials are valid, I return a time limited token. All subsequent requests must have the auth token as a header, which is checked and if valid access is allowed. I maintain the list of valid token in code and expire them as required. This is faster than having to validate the username & password on each call and is slightly safer than the username & password being passed in with each call as a token could be stolen, but it is only valid for a small period of time.
All of this this must be run under SSL otherwise the data is not secure and users credentials can be read.
Basic auth is handled by the server however the server chooses to handle it. There certainly doesn't have to be a plaintext file containing usernames and passwords! My current client stores passwords in a 1-way salted hash in their database. On an incoming request, the plaintext password is pulled from the header, salted, hashed, and them compared to the database value.
Putting a password in a request parameter is a really bad idea. What happens when a user copies and pastes a URL to email to their coworker?