I've copied a custom user flow for PasswordReset. After successful reset of password I'm getting error
AADB2C: Encryption key must be a 256-bit key
The original policy works fine.
What could be wrong here?
After hours of research and trail&error I finally found a solution for this.
When using the Microsoft Identity Web package it works fine. Perhaps some setting in this library does some background magic and sets necessary client keys or tokens so that after successful password change now the user is redirected to the start page of my application.
Related
Hi, Currently we are working on a web application and we are using JWT for authentication once user login successfully for the respective request.
My question is If some how the secret key for generating signature is out so server to ensure security the secret key need to be updated and server need to be down and user must be asked to login again.
Is there is any better solution in such condition?
Are you asking about what to do if the private key is compromised? Yes, then you need to update to a new private key and invalidate everybody's sessions. There is no better solution because you cannot distinguish between a validly generated session and a maliciously generated session.
I'm working on implementing 2FA with Google Authenticator on our website. If I understand correctly every user will have their own secret code, which I will need on login to verify the 6 digit code they enter.
Storing these secret codes in the same database as the user passwords seems like a bad idea (although, if someone got a hold of the database we have bigger problems), is there anyway around it? Or should they just be treated like a password and encrypted?
You cannot hash the secret used to generate the TOTP code for Google Authenticator because you need the original secret to actually generate the code.
It pretty much is as you say, if someone has your database then you're in bigger trouble anyway. However this is how 2 Factor Authentication is supposed to work. If the password is indeed hashed securely and the attacker has only the TOTP secret then all they can do is generate 1 out of the 2 factors required to login and they have more work to do to break or steal the password.
If you'd rather not worry about storing these secrets for your users and letting a third party take care of it, can I recommend you take a look at Twilio's Two Factor Authentication API. Full disclosure, I work for Twilio, but if you don't want to worry about looking after secrets that you can't hash, as well as take advantage of other things like the Authy app (including secret transfer without QR codes) and the extra device data that is now available with authentications then it might be of interest.
You are right.
Is true that the 2FA increase the user security, but is not so strong at server side by definition. If a hacker or malicious employee with database access dump and publish the users secrets, the adtional security is gone.
What can be done ?
You can create a external isolated microservice, that receive a user hash and generate a 2FA secret keys, cryptography it and store in a key-value database, like elasticsearch. You can set the cryptographic key dynamically after the server start, to not store it hard-coded. You can store the database at a external server where the employees have no access other than via API.
This way if a malicious actor dump the elasticsearch database, they can not know what is the secret, and even if he gain access to the crypto keys he doesn't know who is the user that use that secret, because the key is the user id hash(not the user id).
Nothing is perfect, but 2FA targets to make harder to a attacker to have success. I think it help.
In my web application I need to validate the JWT authentication tokens which I get from Live SDK 5.6.
A while ago the signature of those tokens was a HMACSHA256 hash of base64 encoded header+payload using signing key which was the app secret (from account.live.com/developers/applications) + "JWTSig".
It seems that is not the case now.
Does anyone know how are those tokens signed now?
Sorry for my english.
The best way to do this is to get the JWT token returned from Azure Mobile Services and validate it was signed using the same master key from AMS. There is a project on GitHub that shows how to do this:
JWT Validator
This was basically a derivative of another GitHub project that has the original ASP.NET sample here:
AuthenticationTokenSample
The main validation occurs when calling the ValidateSignature() method which takes the bytes of the UTF-8 representation of the JWT Claim segment and calculate an HMAC SHA-256 MAC on them using the shared key from Azure Mobile Services. If the JWT Crypto Segment and the previously calculated value then one has confirmation that the key was used to generate the HMAC on the JWT and that the contents of the JWT Claim Segment have not be tampered with.
The one main thing I found is to remove the appended "JWTSig" string from being appended to the master key in the ValidateSignature() method. It appears the tokens being signed no longer append that string to the master key anymore from AMS. I had all sorts of trouble getting the validation to pass until I removed that segment.
I need to create a login token that I can pass from site 1 to site 2 in a querystring. I don't need to transfer a username or id, I just need to know on site 2 that the user has a valid login on site 1.
I currently create the token like this
timestamp|sha256(timestamp+secret)
On site 2 i create a sha256 of the given timestamp+secret, and match it with the given hash. I also check the timestamp, and doesn't validate if it's older than 5 min.
Is this a reasonably safe way of doing it?
Would it be easy to crack open the sha256 and get the secret?
You can use an HMAC to provide an authenticated message between two parties that already have a shared secret key. What you have described is very similar to an HMAC, because its a type of Message Authentication Code. Although I would actually use an HMAC function to do this.
To crack an hmac you have to brute force secret using the the Authentication Code (the hashed part of the message). The attacker knows the timestamp, so they can keep guessing the secret. Just make the secret really large and very random, like some output from /dev/random is a good choice.
As #Rook says, you should use HMAC to authenticate your tokens.
Additionally, You need to ensure that your tokens can't be stolen. E.g., if you send that token in cleartext—either from site 1 to the user, or from the user to site 2, anyone listening in (think Firesheep) could also "prove" they have an account. The best you can do to prevent that is to use SSL/TLS.
We have a webapp written in .NET that uses NTLM for SSO. We are writing a new webapp in Java that will tightly integrate with the original application. Unfortunately, Java has no support for performing the server portion of NTLM authentication and the only library that I can find requires too much setup to be allowed by IT.
To work around this, I came up with a remote authentication scheme to work across applications and would like your opinions on it. It does not need to be extremely secure, but at the same time not easily be broken.
User is authenticated into .NET application using NTLM
User clicks link that leaves .NET application
.NET application generates random number and stores it in the user table along with the user's full username (domain\username)
Insecure token is formed as random number:username
Insecure token is run through secure cipher (likely AES-256) using pre-shared key stored within the application to produce a secure token
The secure token is passed as part of the query string to the Java application
The Java application decrypts the secure key using the same pre-shared key stored within its own code to get the insecure token
The random number and username are split apart
The username is used to retrieve the user's information from the user table and the stored random number is checked against the one pulled from the insecure token
If the numbers match, the username is put into the session for the user and they are now authenticated
If the numbers do not match, the user is redirected to the .NET application's home page
The random number is removed from the database
1) Having a pre-shared key stored in a file (even a program file) is theater and not security.
2) Your tokens (random numbers in the database) should be set to expire. I suggest expiring after one attempt, but a time limit should be set too. Otherwise you could end up with thousands of leftover tokens that provide access with the right guess.
3) If all you need to do is verify from the Java tool that access is permitted, you can use public key cryptography and not pre-shared keys. That way you only need to protect the private key. Of course, protect includes: "don't put it in a file accessible by the user you are protecting it from," and without that protection, this approach is no different from pre shared keys.
4) It seems ot me that the java tool could be easily modified to ignore the authorization step and just perform whatever sensitive task you are trying to protect.
Take all of this with a grain of salt, as I know relatively little about Java and .NET. I do know a bit about cryptography though.