Assurance

["Roy, Nicholas S" <>]

A short-lived one-time use token in an email is effectively just a very high-entropy password for the person’s account only usable via a specific endpoint.  Combined with other challenges (knowledge-based authentication) then yes I think it’s effective, but the time period it’s active is also exactly the time frame when it would be desirable and possible to snoop it off the wire via SMTP in the clear.

 

Nick

 

From: [mailto:] On Behalf Of Eric Goodman
Sent: Monday, June 04, 2012 3:45 PM
To:
Subject: Re: [Assurance] credential renewal or re-issuance

 

I think I fall into Scott's category on this as well. 

 

I'll add that just because you mail a one-time use reset token doesn't mean you can't add other security to the reset process. E.g., the one time use reset token allows you to be prompted to answer other security challenges, both of which are required for a reset. 

 

Currently we don't use email, and instead rely on just security challenges. I'm guessing we'll to move to a hybrid approach that also relies on email, but it's fairly early on for me to be too sure .

 

--- Eric

On Mon, Jun 4, 2012 at 1:02 PM, Jones, Mark B <> wrote:

I don't think that sending "A short-lived single use Secret sent to the Address of Record that the Subject must submit in order to establish a new Authentication Secret" is the same as "emailing passwords to people".  I'm not saying that the former is perfect, but it does considerably restrict who has the opportunity to control the account over the later.

-----Original Message-----
From: [mailto:] On Behalf Of Roy, Nicholas S
Sent: Monday, June 04, 2012 2:20 PM
To:
Subject: RE: [Assurance] credential renewal or re-issuance

"I expect this could be another "I don't think it's Silver-quality, but Silver does, so I'll shut up now" things."

I think it's one of those things.  I have decided to take Silver for what it is, not what I think it should be.  If it was what I think it should be, it would be impossible for me to implement without bringing up an entirely separate IdP and credential store, including all sorts of special and difficult to implement things for credential issuance, credential re-issuance and entropy control.

Because Silver is written the way it is, I fully intend to utilize things like e-mail (with all its inherent non-security) for credential issuance and re-issuance.

That said, I think it's odd that preventing snooping passwords off the wire (even if limited to a wire that "we" "own"), hashing passwords in an (in my opinion) over-prescribed way and setting complex (and I could argue, counter-productive) password policies to meet an academic definition of password-based authentication security is required, but you're allowed to email passwords to people at registration time.

Nick

-----Original Message-----
From: [mailto:] On Behalf Of Cantor, Scott
Sent: Monday, June 04, 2012 10:17 AM
To:
Subject: Re: [Assurance] credential renewal or re-issuance

On 6/4/12 11:05 AM, "Tom Scavo" <> wrote:

>In section 4.2.4.3 ("Credential Renewal or Re-issuance") of the Silver
>IAP, it suggests "A short-lived single use Secret sent to the Address of
>Record that the Subject must submit in order to establish a new
>Authentication Secret," which could be interpreted as using email to
>deliver a short-lived secret for the purposes of password reset. However,
>email-based password reset is vulnerable to a lost or stolen mobile phone
>(since mobile phones invariably have access to all the user's e-mail
>accounts) so I'm wondering how people plan to handle password reset for
>Silver compliance?

I can't imagine that's the most significant security risk to using email
for this, so if you think email's secure enough (I don't), I wouldn't
think a lost phone would be a concern.

Also interested to hear the opinions of others. I expect this could be
another "I don't think it's Silver-quality, but Silver does, so I'll shut
up now" things.

-- Scott