I'm currently building my web application with identity server 4. I dynamically create clients with a secret generated with Sha256() method of identityserver 4.
However, i'm worrying that when i will renew or change my certificate all those secret will be invalidate which will pose a serious problem.
Are SHA256 linked with the certificat ? Or only Token will be invalidate?
Thanks!
No, the signing credential used for token signing and validation has nothing to do with the hashing of secrets.
Related
I completely don't understand the next-auth documentation.
I understand you can use both JWT and sessions, but how do you tell next-auth which one you're using?
And where does next-auth store its sessions or JWTs? On the server or client-side?
NextAuth.js uses a JWT to save the user's session by default, when a database adapter is not used.
NextAuth.js by default uses JSON Web Tokens for saving the user's
session. However, if you use a database adapter, the database will be
used to persist the user's session. You can force the usage of JWT
when using a database through the configuration options. Since v4 all
our JWT tokens are now encrypted by default with A256GCM.
The JWT is stored in an httpOnly cookie, not accessible on the client-side.
You can use JWT to securely store information you do not mind the
client knowing even without encryption, as the JWT is stored in a
server-readable-only cookie so data in the JWT is not accessible to
third party JavaScript running on your site.
This is documented in NextAuth.js JSON Web Tokens FAQ section.
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
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.
I'm developing a REST web API that will be used by mobile app clients. I don't want any other client to be able to access the API. Should I just require a password/token that will be used by the mobile apps? Isn't there a way for people to find that password by decompiling my app?
Yes, you cannot create an app with a secret embedded and expect the secret to stay secret.
If you ship the app with the secret (token, user/pass, private key, etc), that information is available in the binary, and someone motivated could extract it.
The normal practice is to install the app, then let the user of the application log in, and store a unique credential for future requests.
You could use OWIN OAUTH where a user of the client is required to authenticate and a Bearer authorization token is returned to the client that must be passed in to all secure requests on the WebAPI (a secure request on the WebAPI uses the Authorize attribute)
Take a look at this link http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/#comments
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