I have an asp.net web API. I implemented a token authentication that I am trying to validate user name and password from the database. I am new to JWT so I need your advice.
Here are my questions;
Should I encrypt username and password in my database?
The client sends the username and password in the request body, Should the client send them in the header? And should they be encrypted?
Best Regards.
You should absolutely encrypt your password in the database. Even better if you hash it with "salt" (hashing will let you implement the log in logic, but the original password will be unrecoverable even if you know the hash).
Sending the password in the request body is fine if the connection is protected by TLS (HTTPS). There's no gain in putting it in the headers.
Usernames are often stored in plain text.
P.S. Your question has nothing specific to JWT, it is just general password management.
Related
I have default auth implemented in Laravel 7 and works like a charm.
However, I have a very peculiar requirement wherein, the password shouldn't even travel in plain text although SSL is implemented on network.
One way would be to handle it via javascript on login page wherein I encrypt the value of password and send the same to server and then decrypt the same in php before handing it to laravel attemptLogin method.
However, I am not so sure about this approach.
Any help would be awesome.
Solution:
On client side, used crypt.js/aes.min.js and encrypted the password using a key and iv.
In login controller, overrode credentials method and decrypted using openssl_decrypt before passing on to hash check.
This is already discussed on this answer:
It is standard practice to send "plaintext" passwords over HTTPS. The
passwords are ultimately not plaintext, since the client-server
communication is encrypted as per TLS.
And this one:
If you hash on the client side, the hashed password becomes the actual
password (with the hashing algorithm being nothing more than a means
to convert a user-held mnemonic to the actual password).
This means that you will be storing the full "plain-text" password
(the hash) in the database, and you will have lost all benefit of
hashing in the first place.
You may also read this answer for more security options.
I solved it as below:
On client side, used crypt.js/aes.min.js and encrypted the password using a key and iv.
In login controller, overrode credentials method and decrypted using openssl_decrypt before passing on to hash check.
I'm currently planning to use JWT to secure my API, I have read several tutorials, and find that generally, it's using username and password to generate token, while the UserDetail is got and constructed from a database.
Now I have a question, if I cannot get the UserDetail for some reason, can I use some random data, like UUID replacing username, to identify each request?
update:
I feel if I just use the token to distinguish per request, actually it's not so called oauth2, it's just JWT token.
Actually previously our solution is, we generate a token and store it in Redis before each request , then we verify if the token expires in Redis in each request.
As the customers don't need to login to purchase something, we don't have UserDetail info, Now I feel almost no difference between two solutions, and I'm even wondering if the JWT token alone gives better security.
^_^
Sorry for such novice question.
I am fairly new to web security.
Can someone please explain to me, why do we need JWT token authentication for web api (REST) when I could include { username | email } / password for every single API request?
Mostly, it's a separation of concerns thing. JWTs are a way to authorize a request, whereas username/password is a way to authenticate. The key difference is that authentication is something you should ideally only have to do once, and it should be done by a dedicated endpoint responsible for that. For every other request, you're simply confirming the authorization you received from that initial authentication.
If you were to send username and password with every request, every endpoint then would have to handle authentication logic, which would be a nightmare. Using a JWT, the endpoint can simply verify that it's valid and move on to what it's actually responsible for.
JWTs are just one method of authorization. In a traditional website-style application, this would be handled by a cookie. This then enables the user to login once, and then proceed to browse protected areas of the site without having to login again. The equivalent of what you're suggesting would be essentially like forcing the user to login again everytime they clicked a link, just to view that next page.
I created a WEBAPI solution and I am creating the HTML pages to access all the functions of that web service. I am using http basic authentication.
I got these options
Save the username and password in a Javascript vars and send them every time I call any of the WEBAPI functions.
Send the username and password the first time, create a token on the server and send it back to the client, then save it as a cookie and use it every time I call any of the WEBAPI functions.
Dont use HTTP basic authentication.
What is the best way to handle this?
Thanks
You don't want to send the username / password on every call for security reasons.Token based authentication would be the way to go and you can use the built in identity authentication for that.
The best tutorial I have found for that is http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/
There's nothing wrong with using basic authentication as long as it is done over a secure channel. If you send the username and password on every call, your api will need to access the database on every call just to authenticate the user. If you send a token when the user is authenticated, then you remove the need to access the database on subsequent calls.
Using a token also allows you to take advantage of an identity provider such as Thinktecture's IdentityServer to provide single sign on. If you have more than a few systems, it will allow users to log in one time and then access any of the applications and it can greatly simplify security.
i have a question if using SSL will encrypt both the query string and the Post request body which contain the fields values ?
and if the answer is yes,,
Then does this mean that i can be 99% confidence than an attaker will not be able to modify both the query string & the post body request?
BR
Then does this mean that i can be 99% confidence than an attaker will not be able to modify both the query string & the post body request?
SSL only encrypts and hide the information from a third party. However the hackers own request he can do whatever he wants with them, even if they are sent encrypted. As I said SSL only protects against a third party, not anything else.
A golden rule in all web development is, NEVER trust input data, Encrypted or not.
even if the attacker is Authenticated using a username and password to my web site.
The hacker can send whatever he see fit to the server, his request will be encrypted and protected against a third party, but he can send just whatever he want and your code, if you do not folow the line of never trust input data, he might breach into your server yeah.
So yet again SSL ONLY protects against a third party ( and even that some times not )
If you're using SSL, then yes, you can be sure an attacker will not be able to modify the query string or post data. SSL authenticates the server to the client to prevent anyone successfully impersonating your server. It also encrypts each message sent back and forth using the server's private X.509 key, so that no intermediary can decipher them.