Hiya, On 27/05/15 14:06, Alexey Melnikov wrote: > Hi Stephen, > > On 27/05/2015 13:56, Stephen Farrell wrote: > [...] >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> 4.1: zero length password - I think you're wrong on that >> one but it is arguable. If RFC4013 also prohibited zero >> length passwords (I couldn't tell at a quick glance) > Yes, zero length password was always prohibited by RFC 4013. If you look > at various RFCs that reference SASLPrep, they say "if the password is > invalid or zero length after applying SASLPrep normalization, then > reject it" (or similar words).
That wins. I'll clear the discuss and make this a comment. >> or if >> the WG did debate this and having done so decided to >> prohibit zero length passwords then I will clear the >> discuss immediately. But if not, I'd like to chat about >> it... >> >> There are situations where an empty password is ok (say >> when I'm not "protecting" something but just want to know >> what user's profile to use, e.g. for weather) and that is >> supported in many systems (that hence won't be able to >> exactly adopt this) and insisting on a non-empty password >> could be more damaging than allowing a zero-length >> password, whenever a user re-uses a password for something >> for which no password is really needed (and which hence is >> less likely to be well protected) and where that password >> is also used to protect something of significantly higher >> value. The zero-length password is also not an interesting >> subset of the set of stupid passwords really so doesn't >> deserve to be called out as such (and you say that in the >> draft when you talk about length-1 passwords.) So I think >> allowing zero length passwords is better overall, and more >> consistent with implementations. > The main reason for disallowing it was because with SASLPrep (or > Precis), a non empty sequence of characters can result in empty password > after canonicalization, which seems misleading/dangerous if allowed. >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - Unsurprisingly, the diff between this and RFC4013 isn't >> useful, so I read from scratch. If I'm commenting on >> something that was already true of 4013, just tell me and >> that'll be fine. >> >> - intro: given the unsolved i18n issues and the fact that >> passwords are crap (security wise) would it be fair to ask >> that you add a sentence here to encourage folks to not use >> passwords at all but some better form of authentication, >> when that's possible? (Which is sadly not nearly common >> enough for user authentication.) > Can you suggest specific text? It is a bit hard to agree/disagree in > abstract. Will do in the updated comment. Cheers, S. > > _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
