Subject: [scim] A short review of the password mgmt draft - Management requests

From: Erik Wahlström neXus <[email-masked]>
Date: Tue, 5 May 2015 16:52:05 +0000

Second email in the very exiting series of Erik reading through the password mgmt draft :)
————

Password reset flow are super scary. But I guess the most common way for us to reset password is using, by device policies, a PIN protected phone. This means that an administrator have pre-configured a user with a phone number (or it’s read from AD). This can then by used by the user to get out of the dreaded challenge/response flows.

As long as you have a phone number, you can at least have some kind of semi-secure password reset flow. I guess the flows looks kinda like the section "2.4.2.  Reset With Email Confirmation”, but I don’t really get how that would work. An OTP is sent to the user, how should that later on be sent to the server again? Would that be a pre-configured way by the client to then automatically send a normal "2.4.1.  Password Reset With Challenges” but that it would look kinda like this instead:

POST /PasswordResetRequests  HTTP/1.1
Host: example.com<http://example.com>
Accept: application/json
Content-Type: application/json
Content-Length: ...
{
    "schemas":
        ["urn:ietf:params:scim:schemas:core:2.0:password:PasswordResetRequest"],
    "userName":
        "happyAlice",
    "challenges": [
    {
        "challenge”:”sms-otp",
        "response”:"123ABC"
    }],
    "password": "<new password>"
}

I’m missing more attributes on the PasswordResetRequest functionality also. Sometimes a user have to enter both, username, phone number and email and they all have to match against attributes on the User to be able to send out an email or an SMS. Don’t really see how that would be implemented in current draft’.

————

PasswordValidateRequest would need to be able to specify what password? Is it for the password based method or for the 2FA method (see other email)?

——

DOn’t have the requirement, but would be interesting to see if sms could also be a part of a UsernameRecoverRequest request.

———

/ Erik

---

From: Phil Hunt <[email-masked]>
Date: Tue, 5 May 2015 10:13:12 -0700

Erik

Thanks for your comments.  Re your previous email, I agree.  The higher-level notion of credentials and multi-factor policy make a lot of sense. I think Tony echoed this in Hawaii.

The password reset stuff bothers me the most. I think some more group discussion (such as other factors/methodologies) would really help here.  The current draft really reflects common practice and not what I would call “good” practice (in the absence of other security measures).

In addition to SMS, it would be nice to support strong-auth mechanisms (e.g. from FIDO).

Phil

@independentid
www.independentid.com
[email-masked]

> On May 5, 2015, at 9:52 AM, Erik Wahlström neXus <[email-masked]> wrote:
> 
> Host: example.com <http://example.com/>
> Accept: application/json
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Erik Wahlström neXus <[email-masked]>
Date: Wed, 6 May 2015 20:08:06 +0000

> On 05 May 2015, at 19:13, Phil Hunt <[email-masked]> wrote:
> I think some more group discussion (such as other factors/methodologies) would really help here.  

Common methods, of the top of my head, that we see asked for by 2FA customers.

1. I guess my personal favourite is having a super-admin that can reset a password for a user in an admin system. But that’s only a luxury that corporation with a Man have and it’s an hard method for cloud providers to use.
 
2. Another method we get a lot of questions about is someone helping out and resetting the password. So it’s done by a trusted third party in the form of a boss, IT-dept, colleague or whatever the reset policies defines. There OTPs are sent to the boss and it’s given to the user over some alternative channel (visual or by phone).

3. Then we have reset functions that's using a second channel like a phone or 2FA token somehow. If it’s a phone then it could potentially lower a two factor based authentication to a one factor if it’s not handled correctly. 

4. Then we have, my personal least favourite, challenge/response based methods. I see requirements for that less and less around Europe. 

/ Erik