What about handling single sign on for multiple applications - what do I put in the cookie if anything?
If I am encrypting a cookie what scheme? What key rotation? How many failures of a cookie to decrypt is suspicious
What about password reclamation - do I keep the answers to their grandmothers maiden name in the same database? What about adding a new email address to the list of ones I will mail a password reset token to - do I force them to prove ownership of the first email address before adding the second ? Or will a SMS to their phone do?
I am sure I am missing a hundred items and none of them are to do with bcrypt vs scrypt. Thus is hard stuff and I am avoiding most of it with the magic words "Mozilla persona" but I still don't know how to do sso well. I can do not badly but not well.
Edit: I am being a bit snipy and I apologise but I know I am in deep waters and would be happier if NIST were producing reference implementations. Perhaps actually they have - there is kerberos. If you want a key visit room 303 with your passport
I don't think you're going to see a reference implementation of resetting a password via SMS from NIST any time soon. They make standards for everybody. As soon as you start using words like database and email, you are ruling out lots of applications that don't have those features.
Sounds like I misinterpreted what you were asking. Yes, those are some tricky problems. It looks like our best choice for a longer-term answer is Persona, but it'll be a while before it's as slick as it should be. :-(
Unless Persona drastically changed in the last couple months, it seems to fundamentally misunderstand the problem of user authentication by assuming email addresses are both canonical and authoritative.
Most people keep an email address for years and that's a lot more than own their own domain.
I simply don't know what would work better than an email address as a virtual identifier - if u have a suggestion please (seriously I want to know) say
edit: wow am I in a bad mood. sorry! I would still like to know if there is a better answer than email addresses - but more politely. Cheers
When people decide to change their email address, they don't want to lose their accounts, and when someone else gets their old email address, they shouldn't have their accounts compromised. Seriously: even just "username" is better than email address. All of the advantages of using an email address as the primary key for an account are either not true or actively dangerous once you realize how little they mean to the vast vast majority of "normal people".
Facebook is a reasonable example: they allow you to use email addresses to log in, but your account is not tied to your email address. Ever since nearly forever, they have let you add new email addresses to your account, and you can remove old ones. They also seem to have some schemes in place for mitigating "I lost access to my University email address, and someone else got it" (which one would imagine to be nigh unto endemic for their use case).
Changing addresses can be dealt with just as it is today:
Let logged in users add additional email addresses to their accounts.
Other people getting your old email address is a bit worse. The easy solution is for providers to not reuse names. You could extend the protocol with a version token, so a provider could say that new bob is different from old bob, and shouldn't be able to log in to old bob's account.
Face books use case is a pathological case from universities back when a 10MB hard disk cost more than a professor. Universities do reuse email addresses but that's policy not need - and even universities can change policy.
Username is horrific as a global identifier - I hate easily.co.uk every time my browser cache gets cleared.
Adding new addresses to an account works and really ISPs ought never reuse emails. A new RFC perhaps?
What about password reclamation - do I keep the answers to their grandmothers maiden name in the same database? What about adding a new email address to the list of ones I will mail a password reset token to - do I force them to prove ownership of the first email address before adding the second ? Or will a SMS to their phone do?
I am sure I am missing a hundred items and none of them are to do with bcrypt vs scrypt. Thus is hard stuff and I am avoiding most of it with the magic words "Mozilla persona" but I still don't know how to do sso well. I can do not badly but not well.
Edit: I am being a bit snipy and I apologise but I know I am in deep waters and would be happier if NIST were producing reference implementations. Perhaps actually they have - there is kerberos. If you want a key visit room 303 with your passport