<div dir="auto"><div dir="auto"><span style="font-family:sans-serif">On Apr 2, 2017 00:39, "Arnold Reinhold" <<a href="mailto:agr@me.com" target="_blank">agr@me.com</a>> wrote:</span><span style="font-family:sans-serif"><br></span></div><div><span style="font-family:sans-serif">> What you suggest may make sense in an historical context,</span></div><div dir="auto"><span style="font-family:sans-serif">> it's the best explanation I've heard so far, but sending clients their</span></div><div dir="auto"><span style="font-family:sans-serif">> password requires that the computer service provider store the</span></div><div dir="auto"><span style="font-family:sans-serif">> plaintext password, which is bad practice and is totally prohibited by</span></div><div dir="auto"><span style="font-family:sans-serif">> the NIST 63B draft. So it's not a justification for space elimination</span></div><div dir="auto"><span style="font-family:sans-serif">> being allowed in 63B.</span></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">While I personally think it also is bad practice, it certainly does NOT require the service provider *store* a plaintext password (at least permanently). You can store via bcrypt, scrypt, etc., whatever way you normally hash it (complete with using a random salt) and just put it through similar authentication processing. The major difference in the authentication is that:</font></div><div dir="auto"><font face="sans-serif">1) upon successful authentication, you force the user to immediately change their password to something of their choosing, and</font></div><div dir="auto"><font face="sans-serif">2) you generally place a tight time limit on how soon such an emailed password must be used. Say no more than 12 hours, but ideally, maybe 15-20 minutes max. (Presumably, since the user took some action to have the password emailed​ to themselves [e.g., user registration, forgot password flow, call to help desk, etc.]. The user will be expecting the password in an email, to its expiration period can be short.)<br></font><br>I think the practice of emailing such temporary passwords is dumb for other reasons (some of which can also be overcome with additional complexity), but requiring that the temp password be stored as plaintext is not one of them.</div><div dir="auto"><br><div data-smartmail="gmail_signature" dir="auto">-kevin<br>--<br>Blog: <a href="http://off-the-wall-security.blogspot.com/" target="_blank">http://off-the-wall-security.<wbr>blogspot.com/</a>  |  Twitter:  @KevinWWall<br>NSA: All your crypto bit are belong to us.</div></div></div>