search

SmartTokenLabs / attestation

Paper and implementation of blockchain attestations
MIT License
48 stars 10 forks source link

Email not validated in DevCon flow #267

Closed jot2re closed 2 years ago

jot2re commented 2 years ago

The user's email is not validated by attestation.id when issuing attestations based on a magic link. I.e. the ticket issuer is trusted to implicitly do the validation through the secret in the magic link.

See section 2.2.5 in the Token-negotiator report. See (Jira issue 291)[https://smarttokenlabs.atlassian.net/browse/PR-291].

jot2re commented 2 years ago

@weiwu-zhang as far as I have understood from you, this issues goes against both the scope of what we want of attestation.id, but it also goes against the threat model. However, this greatly increases usability and I think it might be "won't fix" issue. Can you confirm if this is the case or not?

oleggrib commented 2 years ago

@jot2re , we dont use attestation by magic link nomore, because it generate valid emailAttestation and user can use this emailAttestation for other projects and it means that one-time magicLink lead leads to forever emailAttestation compromise.

in case if we need emailAttestation based on magicLink then we need to limit emailAttestation per token and this need to share tokens schema/keys with attestation.id, but attestation.id should stay separate independent project.

@weiwu-zhang , am I right?

SmartLayer commented 2 years ago

Won't fix until DevCon is over.

SmartLayer commented 2 years ago

@weiwu-zhang as far as I have understood from you, this issues goes against both the scope of what we want of attestation.id, but it also goes against the threat model. However, this greatly increases usability and I think it might be "won't fix" issue. Can you confirm if this is the case or not?

Wont' fix till DevCon is over.

oleggrib commented 2 years ago

@weiwu-zhang , devcon confirmet to use OTP email confrmation, so we dont use magicLink attestation in our projects at the moment. Is it OK? cc @AW-STJ

jot2re commented 2 years ago

@jot2re , we dont use attestation by magic link nomore, because it generate valid emailAttestation and user can use this emailAttestation for other projects and it means that one-time magicLink lead leads to forever emailAttestation compromise.

@oleggrib my understanding was that the attestation validity was still time restricted to 1 hour or 1 day (at least it was the case the last time I went through the attestation.id flows). Is that not the case anymore? Or do you simply mean that because the user has access to the magic link, they can always construct a new email attestation?

oleggrib commented 2 years ago

@oleggrib my understanding was that the attestation validity was still time restricted to 1 hour or 1 day (at least it was the case the last time I went through the attestation.id flows). Is that not the case anymore?

current emailAttestations with Auth0 flow has TTL 1 month,

Or do you simply mean that because the user has access to the magic link, they can always construct a new email attestation?

yes, exactly, this is why we dont use it. @jot2re

jot2re commented 2 years ago

No longer relevant; has been fixed. Closing the issue.