Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
How about not storing anything in the database and use something like jwt?
You could create a jwt token with the necessary stuff you'll need and an expiration, send a link to the e-mail, the link posts the jwt token to some api or whatever and that's it. Boom saved database storage😎
Otherwise, yes use the same db and just define the type what token that is -
@SuspiciousBug
I tested on selly.gg for example how they did it.
Heres the url when i clicked the reset password link in my email:
https://selly.io/users/password/...
/users/password/edit?reset_password_token=G_MzMx4LEj1vi97xo2_6
Exactly the token im also talking about
-
@b2plane
It is not any less secure at all.
Email verification is supposed to be an idempotent operation (have you looked up the word yet?). It doesn't matter if you do it 100x times. The result is the same, the user is verified.
Password reset is not idempotent, but it's simple to implement assuming you have "updated_at" fields in your passwords table. Check the iat claim of the jwt vs the updated_at field of the password.
If iat is earlier, it was already used.
No need to store anything in a database, and as secure as any other token scheme. (Remember, JW *Token*)
And no need to run any housekeeping on expired shit because checking for expired tokens is part of validation. -
@b2plane why is it less secure and why would you need to store the jwt in the db?
-
@b2plane
The JWT *is* the authentication.
User inputs their email address, id or whatever and hit reset password.
You create a jwt with that id as sub, and reset password as aud, or as custom field, sign it and include it in your mail template, then you send the mail.
When your backend receives the request in the mail, the token is in the URL. Grab it, verify the signature.
If the token is valid, your user is right there in the sub claim. -
@b2plane
You can't do anything but a plain get without headers from a link. How are you supposed to pass a token if not in the URL?
Nothing in the token is private. You sign it with your private key and you verify it with your public key.
Anyone forging the payload would cause the signature to be invalid, and no one can create a new valid signature without your private key. -
@b2plane
No. You pass the whole token, otherwise it's pointless.
Also, as I've told you other times, I'm not your personal stackoverflow.
If you need to learn more about JWT and how it's used, go brush up on https://jwt.io -
@b2plane
If you are going to mention me please *read*, I'll repeat *READ* my posts, not just skim them.
Anyone that gets the whole token can only do a password reset and only for the user it was meant to.
The token is only ever sent to the user registered mail, which means it is not any more or less secure than mailing any other thing to an email address.
No one but you (or whoever you shared your private key with; HINT: YOU DON'T) can produce a valid token. They can't modify the payload, nor resign it.
For the rest, again, https://jwt.io -
@b2plane
I'm the one telling you that JWT is *one* way of doing it, and that it isn't inherently any more or less secure than other options.
It does have advantages in not requiring any database storage.
If you want to do it other way, that's perfectly fine. Other methods have other advantages. -
@b2plane you want a token for this job. You can craft your own token system, or you can use JWT, or whatever.
I'd recommend JWT, because based on what you've been saying, I don't believe you would create a secure token system on your own accord.
Good on you for learning, but this is a rant room, not a code bootcamp. -
@b2plane
As @lungdart said, you run a very serious risk of just botching any self-implemented scheme.
Based on your post, and I quote
"No one else can get the token".
Wrong. No one else should get *the email with the token*. The whole point of signed JWTs is that they securely authenticate a user in an easily distributed way. Of course sharing such a token is the same as sharing access, but if you do it right, you only provide access for a short time and for specific functions.
Also
"It's locally stored on users' PC unless I do some dumb shit".
It can, or it can not. Depends on use case. If used as a "session" token? Yes. You save it in a cookie and the browser sends it for you in every request.
If used as an access token for an API, you pass it however the API requires. (And needs not be stored anywhere). In this specific case, you can't set up headers or change the method and body of a request in a hyperlink, so you use the URL (which JWT specifies is perfectly safe). -
So yeah. I'm skeptical in your statement that you read my replies and JWT.io and you now know how JWT works.
You may have gotten superficial notions (and that's good already), but you definitely don't know it well, and when dealing on whether something is secure or not, you show delicate gaps in your knowledge, so rolling your own security scheme is 100% doomed to fail in one way or another. -
@b2plane go look to jwt. If you understood it, you wouldn't ask these questions.
-
@b2plane iat and exp claims. This is my last answer to you on this topic.
-
@b2plane you basically send a json which contains the email adress, an expiration time and whatever you need for completing the request. But that json is signed with your key, so no one can create this json object themselve to validate some random email adress without having your secret token. It's not less secure, it expires, you don't need to store it in a database, as you know this request can only originate from that email, because you created and signed that jwt. You don't need to run some cron job to clean old 'tokens', it just works, it does not need maintenance.
-
@b2plane you don't need to save the token anywhere. You don't need to compare the token the user sends you to anything. You validate the signature, and if it's valid, you know all the values in the token can be trusted
-
@b2plane the jwt should not be created nor stored on the client side, only should be send in the e-mail and well then it will be in the url.
Basically
1. User presses password reset, enters email, sends the form to the server
2. The server will create the jwt (with the email as a sub and and expiration time), the jwt will be send as a link to the email for example https://example.com/api/......., the server will reply with a page that says check your inbox and click on the link
3. The user opens the email and the link, the server will receive the jwt token, checks the signature, then checks that it's not expired and then looks at the sub and sees the email and then knows for sure this email is valid and the user could only have this jwt token if they have access to the email adress, then the server responds with a page that lets the user reset the password, the user enters the new password and then sends the form to the server, the server should check again that the jwt in the url is valid and then set the password.
The expiration of the jwt token should be not long, less than 30 minutes, but definitely longer than 5 minutes, as it may take some time to get the email open the link etc... -
@b2plane one thing I'll add to my comment from yesterday, just to be sure it does not get misinterpreted, not only check if the signature is valid but check that the signature originates from your key,
Lets say i have to send an email to the user when:
- user forgot password (email sent with a token to verify the user owns that email, and token identifies for which user is this link valid)
- email verification (email sent with a token to verify the user who just registered, where this token uniquely is generated for each newly registered user)
- etc
Notice how both of these cases include the same shit:
- sending emails
- generating unique tokens
- attaching each record to individual user
Does this mean i should pack this up in 1 single model in the database and differentiate which type of email it is over an enum (EMAIL_CONFIRM, FORGOT_PASSWORD etc)?
Or should these shits each have a different model and thus different tables in database?
rant