email confirmation about explore-flask HOT 17 CLOSED

The data is actually not encrypted when it is passed into itsdangerous. It's serialized and signed. The signature is also included in the token because it can be used to verify that the token was generated by the server and not some random joe on the internet.

The thing that's keeping the token from being generated is the fact that it is signed using the secret key. If the secret key is exposed, then none of the id, email, or a timestamp will stop that from being exploited (timestamps are generally super easy to guess).

from explore-flask.

After reading through this, I think it can be closed as a misunderstanding of how the design works by the OP.

from explore-flask.

This seems to make sense. I need to spend a few minutes looking into it. Thanks for bringing it to my attention.

from explore-flask.

let me know if you'd like some example code

from explore-flask.

As a side note: send_email isn't referencing Flask-Mail, just a generic method to send an email.

from explore-flask.

Could you explain the attack vector a little more to me? Are you saying that multiple accounts might be attached to the same email address?

from explore-flask.

So that someone does not just start generating tokens. If s/he doesn't have
the id then all is well.

On Mon, Dec 8, 2014 at 12:52 PM, Robert Picard [email protected]
wrote:

Could you explain the attack vector a little more to me? Are you saying
that multiple accounts might be attached to the same email address?

—
Reply to this email directly or view it on GitHub
#77 (comment)
.

from explore-flask.

itsdangerous uses the application secret to sign the tokens. I just went looking through the code to confirm, and yeah it's signing them with HMAC SHA256 by default. This is what keeps me from making tokens for other users.

It uses the value passed in when the URLSafeTimedSerializer is initialized. We're doing this with the application secret at line 7 in the first code block here https://exploreflask.com/users.html#email-confirmation.

It's also worth noting that the user id is not a secret value. They are usually easy to guess or revealed in URLs and other places.

If I'm mistaken on any of this please let me know, though.

from explore-flask.

Use both. Then do a final check with the id.

On Tue, Dec 9, 2014 at 9:52 AM, Robert Picard [email protected]
wrote:

itsdangerous uses the application secret to sign the tokens. I just went
looking through the code to confirm, and yeah it's signing them with HMAC
SHA256 by default.

It uses the value passed in when the URLSafeTimedSerializer is
initialized. We're doing this with the application secret at line 7 in the
first code block here
https://exploreflask.com/users.html#email-confirmation.

It's also worth noting that the user id is not a secret value. They are
usually easy to guess or revealed in URLs and other places.

—
Reply to this email directly or view it on GitHub
#77 (comment)
.

from explore-flask.

I think I'm misunderstanding still. What security benefit do you get by including the id?

from explore-flask.

let's say someone figures out how to generate a correct token. if the id is
in there as well, it can be used as a final confirmation. so you verify
email and then id. it's just added secerity.

On Tue, Dec 9, 2014 at 11:27 AM, Robert Picard [email protected]
wrote:

I think I'm misunderstanding still. What security benefit do you get by
including the id?

—
Reply to this email directly or view it on GitHub
#77 (comment)
.

from explore-flask.

What's to stop them from including the id in the forged token?

If they can generate a correct token it's game over.

from explore-flask.

I'm not explaining this very well. Let me show you an example.

On Tue, Dec 9, 2014 at 11:30 AM, Robert Picard [email protected]
wrote:

What's to stop them from including the id in the forged token?

If they can generate a correct token it's game over.

—
Reply to this email directly or view it on GitHub
#77 (comment)
.

from explore-flask.

Sounds good. 👍

from explore-flask.

Okay. Here are my thoughts -

Since the user knows that the encrypted data is just the email, if the salt is hard coded, they could get the secret key. That's one problem. The second is that if you just encode the user id, you would have the same issue since it is sequential. I think it's best to use the user id, email, along with a timestamp.

Thoughts?

from explore-flask.

@rpicard Great book! Can you provide an example for send_email? Perhaps using Flask-Mail or whatever you think is most useful? Would this work?

from explore-flask.

@jeffwidman Yeah, I think you're right.

As for the send_email stuff, there are a million ways to implement it. I personally like using an email service like Mailgun or Amazon SES because it feels easier. I'm going to close this out, but feel free to open a different issue if you have more questions. I'm not always prompt about answering, but I'll try to help. :)

from explore-flask.