<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPhone</div><div><br>On Apr 2, 2017, at 1:31 AM, Kevin W. Wall <<a href="mailto:kevin.w.wall@gmail.com">kevin.w.wall@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><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></div></div></div>
</blockquote><br><div>Sorry, I misunderstood. I thought you were describing a situation where the help desk sent a forgetful user the password they had originally established. In the use case you describe, which I agree has other problems, there is no reason the system generated temporary password would contain spaces in the first place. I've never seen any that did. And I'm not aware of any OS where cutting and pasting into a form field adds leading or trailing spaces, but if that's the problem, only those should be permitted to be removed and perhaps only in the time window during which the temporary password is valid. </div><div><br></div><div>Arnold Reinhold</div></body></html>