I'm working on a 2FA App.
Is there a way for me the secret key a user provides that I use to generate their tokens is valid beforehand?
Edit:
For clarification: I am not providing the login server, but the token generation for the user (think authy or google authenticator)
The only way to validate that the secret is correct is to generate a token and submit it to the service that generated and stored the secret for the user. If the service agrees that the token is correct, then you have the correct secret.
You need to store the generated key somewhere, in memory or in a database. Then when the secret key is sent back, check it with the stored value.
If someone is still searching for this today I searched around little and got to an answer
The following format is a valid totp qrcode :
otpauth://totp/{CompanyName}:{Email}?secret={Secret}&issuer={CompanyName}
Email: dosen't need to really be an email, just a client name "name" or "name#email.com"
CompanyName: companyname can be in format like "example.com" or "example"
Secret: needs to be a base32 formated string
You can read more about it at : https://datatracker.ietf.org/doc/html/rfc6238#section-4
Related
I want to know the api endpoint where I can post username and password and that should return me the auth token. For more clarity I am attaching the screenshot.
I know it's making call to following endpoint but these endpoint are not having any documentation, maybe they are not public.
https://containerimages.azz.net/artifactory/ui/userProfile
https://containerimages.azz.net/artifactory/ui/userApiKey
The APIs you mention in the question are UI APIs. Those are not public and might be a subject to change. You should rely on them.
If you wish to generate a Docker config.json file as the one shown in the screenshot, the auth part is simply a base64 encoding of the <USERNAME>:<PASSWORD>.
For the part use can use:
An access token - this is the preferred method as tokens are revokable an expirable
API Key
Encrypted password
Clear text password
All options should be base64 encoded as mentioned above.
You can avoid storing the Docker credentials in the config.json file by using a credentials store as described in the Docker login documentation.
If you wish to get an Artifactory API key for a user, you should use the Get API Key REST API.
am trying to understand google's auth server response from https://www.googleapis.com/oauth2/v3/tokeninfo?id_token=XYZ123. I got most of it, am only stuck with jti and kid and have no idea what they are for, some one please explain, am trying to find the authenticated user id, or doesn't google provide id for the authenticated user. Thanks in advance
It appears under the hood the google authentication system is supported by Okta. Here are the descriptions of those values from their documentation:
JTI is a unique identifier for this access token for debugging and revocation purposes. Type: String
kid identifies the public-key used to sign the access_token. The corresponding public-key can be found via the JWKS in the discovery document. Type: String
I don't know why google doesn't have it listed in their documentation, but this should be what you need.
Sources:
https://developer.okta.com/docs/api/resources/oidc
https://google.github.io/google-auth-library-nodejs/interfaces/_auth_loginticket_.tokenpayload.html
I have a firebase powered app. The requirement is to update the account password by typing the currentPassword and the newPassword.
On the server (firebase cloud function + admin sdk) i need to check if the provided currentPassword is valid.
When an account is created for the first time, firebase automatically encrypts the password, and gives me back only the hash.
The problem is - this encryption is done automatically, under the covers.
Without having access to the encryption method, i can't obtain the hash of the currentPassword in order to compare it to the stored hash of the real password.. to see if this 2 hashes match.
So how can i check if the currentPassword is valid? How to get access to the same method firebase-auth uses for encryption?
I coudn't find anything relevant so far. am I using the wrong approach here? Why is it so hard to find it ?
I'm not quite sure that you can verify the password with cloud function, the point is to make sure that hackers would not be able to recover users' passwords even if they somehow hacked into the server, if you can recover the passwords by knowing the hash and salt, why wouldn't them hackers? However, you can do that in your app:
firebase.auth().currentUser.reauthenticateWithCredential(firebase.auth.EmailAuthProvider.credential(firebase.auth().currentUser.email, oldPassword);
Also, just to provide an alternative way for users who want to change their password, just send them a reset password email, this way, it's quite safe and they won't have to enter their old password:
firebase.auth().sendPasswordResetEmail(firebase.auth().currentUser.email)
passwordHash and passwordSalt are only available when you retrieve the user information via a call to listUsers(). Therefore they are only useful if you ever migrate user data from Firebase Auth to a different user management system.
For this use-case i needed to implemented 2 different approaches.
case 1: when the agent changes it's own password.
I use browser code as provided by #K.Wu - firebase automatically sends a password reset email to the user.
firebase.auth().sendPasswordResetEmail(firebase.auth().currentUser.email)
case 2: when a high privilege user: admin / manager changes the agent password
I use server code - firebase admin sdk. Here the manager doesn't know the currentPassword, and doesn't need to know since the firebase-admin can change account passwords without needing to send confirmation emails.
Still, What i don't uninterested is this:
When i create the user for the first time, firebase gives me a userRecord object which has 2 properties: passwordHash, and passwordSalt. But since i can't encrypt a given password manually, then what is the use of this 2 properties? When are they ever needed?
I considered them being specifically designed for when you compare the hash of a provided password - with this passwordHash that is stored in firebase. Seems this is not the case, and I'm still confused a bit.
Anyway splitting the password update functionality between client and server, based on who performs the action, as explained above - worked like a charm.
note: also this setup allows for the account creation to be done by admin / manager.
I think you can check against the password hash with scrypt. You need to download the scrypt config from account and compare. Please check the below docs
https://firebaseopensource.com/projects/firebase/scrypt/
Util function for scrypt if found here for hashing and verification
https://github.com/xeewi/firebase-scrypt
Note: Only listUsers() method will return the passwordHash. getUser() or no other function will return the passwordHash values.
I was reading article on JWT web token as an access token that is being response to the user. Some of it mention that the web token should be able to be decoded by the user.
Does it means that it is not a good practice to decrypt the entire web token? For example, I suppose to return following JWT web token to user where this piece of information can be decoded.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
However, I feel that I do not want to let user able to decode his/her access token, so I use another encryption algorithm to encrypt everything into another form as follow and pass back to user.
So, I would decrypt this new text when I'll get this access token in the server and decode it.
Is it recommended to do it this way if I do not wish to expose some of the value available in claim (such as user id) to the user? If not, what are the alternatives?
JWT (RFC7519) is just a compact way to safely transmit claims from an issuer to the audience over HTTP.
JWT can be:
signed (JWS - RFC7515)
encrypted (JWE - RFC7516)
signed then encrypted (this order is highly recommended). The whole JWS is the payload of the JWE
encrypted then signed.
It makes sense to encrypt a JWS if you want to keep sensitive information hidden from the bearer (client) or third parties.
The real questions are: does the audience support JWE? If yes, which algorithms are supported?
JWT are "signed" and therefore its contents are protected from tampering: you cannot change its contents without invalidating them.
You can optionally "encrypt" the contents and therefore turn them visible only to issuer (the entity creating the token) and the consumer (the entity that is destined to use its contents after verification).
There's a standard for that: JWE
A token contains user data and acts like a temp storage. It is not good to store sensitive data in a token.
At the first level, you should store the user name and maybe role or something like that. You should not include passwords, so it does not need to be encrypted.
Nevertheless, you can encrypt it if you want.
Yes, the best practice is use the JSON Web Encryption (JWE) RFC, the claims in the JWT after decode it are in plain text, so if the user lost the token, the sensitive information as email, username, access permissions can be visible and can be used as a the initial information of any attack.
I browse but didn't got proper solution.i am working on asp.net membership all i want to do is to retrieve user password when user apply for forgot password for condition 1. i want password to be in encrypted format in database and 2. retrieve password in decrypted format.is it possible.
Normally, encrypted passwords would be stored using a one way hash. This means
that the password cannot be decrypted once it is stored. Many authentication systems
work by taking the password ( of the user trying to authenticate ), encrypting
it using the same one way hash function as was used to store the password in the
database, and then doing a string comparison in order to determine if the
resulting encrypted password matches the one that exists in the database.
How are you determining if the user requesting the password is actually
the owner of the account ? Perhaps you can clarify your question with details
of the environment so that we may offer alternative solutions.
Use PasswordRecoveryControl
But anyhow it's not advisable to send password in plain text format.