I am a developer with very little experience on the crypto part, and I'm looking for a secure solution (OTP Like) for identifying between client (browser) and server.
this is what i need:
Web Page at 10.00 AM generate a randomly id based on a secret key
User A
• 10.00 AM 258e461ba8b7b66a02cf17dfe60f465c103c742e570f492a31931424f38e0d5c
• 10.15 AM 21309341c1278cbd4670668a81144c06ea27bfdbdf44f1ee0c28a2a7f9a17d34•
• 10.30 AM 34b3b35600af44544c53b05d8d44357774d1f03bff40a6ea81ea196925d71357
...
every 15 min the script generate a new id
when the client send the generated secret id to the server the server with the same secret key it must be able to identify the A user
what algorithm or technique can I use to do this?
Related
I have two applications.
Application 1 has user info stored in its database. It will generate a small token that consists of user info.
Application 1 will send generated token to Application 2 in a GET request with token in query params.
Example:
http://www.app2.com?token=<token_generated_by_app1>
Application 2 will use the token and consider that the user in the token logged in for the application 2 session.
Now to ensure the security of the token, it needs to be encrypted.
What would be a good encryption algorithm for this use case?
Update:
After some searching, I found JWT has a variant call JWE which includes encryption.
https://www.rfc-editor.org/rfc/rfc7516
I am using .NET Core 3.1 in my Web API project. In that, I have used JWT authentication. Now I want to allow users to log in or register using their mobile number. So when the user enters the mobile number an OTP will be sent and after verifying the OTP, I want to issue JWT for the user. Now, I have the below queries regarding this:
If this flow is correct or something needs to be changed?
Where should I store the OTP sent to the user's mobile number? Should I create a separate table for storing OTP and mobile numbers or it should be managed on the front-end site where I am using ReactJs?
Note: I cannot change the authentication mechanism from JWT to any other as I already have dependencies over it.
So when the user enters the mobile number an OTP will be sent and
after verifying the OTP, I want to issue JWT for the user. Now, I have
the below queries regarding this:
If this flow is correct or something needs to be changed?
First, I think the workflow is correct.
Generally, when we using JWT authentication, the workflow as below:
Client sends a request (which contains the user information, such as: name and password) to server for token
Server receives the user information and checking for authorization. If validated success, server generates a JWT token.
Client receives the token and stores it somewhere locally.
Client sends the token in the future requests.
Server gets the token from request header, computes Hash again by using a) Header from token b) payload from token c) secret key which server already has.
If ("newly computed hash" = "hash came in token"), token is valid otherwise it is tempered or not valid
So, in your workflow, you are using Mobile number and the OTP to login, and validate the user. It also is correct.
Where should I store the OTP sent to the user's mobile number? Should I create a
separate table for storing OTP and mobile numbers or it should be
managed on the front-end site where I am using ReactJs?
For this issue, I think it depends on how you generate/send the OTP.
If the OTP is generated by yourself, you have to store the phone number and OTP in the database, because, after client send the phone number and OTP to the server side, you have to validate whether the user is valid or not.
If you are using some provider or package to generate the OTP, might be the OTP has an expired time property, you can also store them in the database. If the expired time very short, there is no need to store them in database, you could try to use session to store the OTP.
I'm using Identity Server 4 and Dotnet Core Identity for authentication service. Authentication service has custom react spa.
I'm trying to get started a authenticate a user using their mobile number. I have a user data (email, password, phone number, etc.)
I want this steps;
User:Key in email and password (done)
Server:Send sms with code to mobile number (?), i have a sms server
User:Key-in code from SMS
Server:Send access token (done)
I developed a project using this example. https://github.com/karpikpl/identity-server4-with-SPA-UI
I have no idea how to integrate two factors, how can I help you? Thank you.
A solution for this issue can be like this:
Step 1
Generate an SMS code in your IDP (Auth server).
Step 2
Store that SMS code as a claim for the user with an expiration time (if needed).
Step 3
When the user comes to sign in to your IDP using his username, you can compare the entered SMS code by the user with that one you stored in DB as a user claim. Also, you may want to check the expiration time of the SMS code.
Step 4
If everything was ok so you remove that claim of the user then log him into your IDP and done.
Suppose a FCM token is generated abcd and assigned to a user say user 1 now this token is no longer associated to user 1 as he uninstalled his app. Can this token abcd be assigned to some other user in future?
EDIT 1:
I know it is unique at a time. But if a token is not being used by anyone abcd will that be used again by some other user as it is still unique as user 1 is using a different token?
EDIT 2:
The token I am referring to is the device regestration token.
The simple is NO
Google/Firebase practice is having a hashing algorithm to generate a long and non repeating id (usually associate with timestamp and other factors), which usually can be up to 20 characters or more, to ensure it is unique in the database (FCM device token db).
Therefore, it will always assign a new and unique token to the new device. Won't reuse the token in any circumstances.
[UPDATE]
Thanks for your comment, now I have a concrete answer to your problem now. Each token contains the particular user meta-data, and other info including unique id etc.
So the token can only be revoked by the same user but cannot be use by others (because it contains the user meta-data).
The documentation about GCM says that token is unique, I think the same applicable for FCM as well.
https://developers.google.com/cloud-messaging/registration
To verify that they can send and receive messages, client apps must register with GCM. In this process, the client obtains a unique registration token...
I'm implementing my own OAuth authentication system (with refresh_token support) for an app and I have some questions about how to do it:
Client identification: The client is registered in the auth server and gets a client_id and a client_secret. How do I generate it? is there some kind of relation between both values?.
User authentication: The client sends the users_credentials (username+password for example) + client_id and gets a refresh_token and (temp?)access_token. That access_token is the one I should use in further request or I should use a accesss_token`=F(refresh_token,access_token,client_secret). In the second case what does the F function consist on?
Access token refresh: The client send client_id, refresh_token and gets a access_token (and a optional new refresh_token). Does the access_token need the same conversion (whatever it be), as in the point 2?
If I'm wrong, when and how is the client_secret used?
Complete answers and concrete examples will be "bountied".
The authorisation/authentication server generates these values when you create an account with them (for instance when you create a developer account with Facebook or Google). If you are doing these parts yourself, they should be cryptographically secure pseudo-random numbers or letters. Remember that the client ID is usually publically visible, so choose a reasonably large set of alpha-numerics (I use 30 characters). The secret is private and can be harder to guess so I chose 30 digits with letters, numbers and symbols. These are not related to each other, it is just that one is public and the other isn't.
The usual way this works is that there is a browser redirect to the auth server passing the client id in the URL (and redirect uri) and specifically NOT the user id and password. The whole point of OAuth2 is that the client system never sees the user name and password, only the auth server. After this redirect, the auth server verifies the client id, checks the username/password (for instance) and then returns to the redirect uri with a temporary code. This temporary code is passed back to the Auth server in order to obtain an access token. Since this call is made as a POST from the server, it also passes the client secret to verify that it really is the correct client system and not someone who stole the client id from somewhere else. At this point, the auth server will return an access token (and optional refresh token - you do not need to use them, I don't).
If the client system wants to log the user in without them having to type in their username and password all the time, it can use a refresh token, if available, to call back onto the Auth server and if the Auth server is happy that the refresh token is still valid and any other business rules are correct, it can give you back another access token directly without the user being involved.
I recommend reading the OAuth2 spec here: OAuth2 Spec RFC6749. It can take a while but if you delete the bits you don't need and reduce the amount of data, there are plenty of useful examples in it.
FIRSTLY, The client identifier can be any string that you want, but it should be unique for each client. It can even be the client's choice if you wish.
The client secret should be a cryptographically strong random string. Here is how you could generate one in C#:
RandomNumberGenerator cryptoRandomDataGenerator = new RNGCryptoServiceProvider();
byte[] buffer = new byte[length];
cryptoRandomDataGenerator.GetBytes(buffer);
string uniq = Convert.ToBase64String(buffer);
return uniq;
SECONDLY, The whole point of OAuth is to allow external apps to do things on your behalf without asking for your credentials. So, you need to implement an authentication server that does the logging in part for you. The user opens the app and gets an option to Log in using your website. You tend out access tokens and refresh tokens once the user has keyed in his credentials. The app can then simply use the tokens to perform actions on the user's behalf. I wrote an answer to How would an efficient OAuth2.0 server / provider work? that explains how access tokens can be constructed.
Remember, the need for refresh tokens and the lifetime of access tokens purely depends on how you intend to use them and what does your security framework look like.
LASTLY, The refresh token can also be an HMAC encoded string/a JSON object as I had explained in the answer to the linked question. You can have random refresh tokens and a large backend storage to keep it to verify the tokens in the incoming requests, or have HMAC encoded strings for added security/less storage requirements/latency to decrypt/encrypt tokens.
Also, do make sure that you go through all the flows and possibly the RFC too as mentioned by Lukos.