- From: Dan Poltawski <dan@moodle.com>
- Date: Thu, 2 Oct 2014 00:48:18 +0100
- To: Gavin Sharp <gavin@gavinsharp.com>
- Cc: Dan Poltawski <dan@moodle.com>, whatwg <whatwg@lists.whatwg.org>, pkasting@google.com
On 2 October 2014 00:34, Gavin Sharp <gavin@gavinsharp.com> wrote: > The underlying use case seems to be obfuscating text in an input field > that isn't a password. From a spec perspective, a feature to opt-in to > obfuscation that isn't type=password could address this (e.g. > type="masked-text"). Yep, exactly. Thanks for putting it more eloquently than me! On 2 October 2014 00:34, Gavin Sharp <gavin@gavinsharp.com> wrote: > On Wed, Oct 1, 2014 at 4:17 PM, Peter Kasting <pkasting@google.com> wrote: >> So, you're doing both of the following? >> * Using a password field for (sometimes) things that aren't passwords >> * Storing (potentially) sensitive data in the clear yourself, and sending >> it (again, in the clear) to other accounts/machines > > I probably shouldn't speak for Dan, but I think you're > misunderstanding the use case here (particularly with characterization > #2). The data being intentionally stored in these fields is not > "sensitive", in the sense that it can't be shared in the clear to > other users (teachers), it just needs to not be displayed on the > screen (where it can be viewed by students). > > That browsers now automatically go fill in sensitive data (passwords) > into these password fields is the issue, because people might not > notice that happening and then submit the form. Correct. thanks, Dan > > Gavin > > On Wed, Oct 1, 2014 at 12:19 PM, Dan Poltawski <dan@moodle.com> wrote: >> Hi All, >> >> Over the past few months all the browser vendors have moved towards >> ignoring autocomplete="off" with password fields. I understand the >> rationale behind this, but in our software project this has lead to >> the frustrating situation where we seem to have no good option to deal >> with this and the change is actively harming the security of our >> users. >> >> To outline the situation in broad terms: >> * We have shared secrets on the page which we protect against shoulder >> surfing by using the password element with autocomplete="off" >> * The password managers are now all auto-filling these fields with >> passwords on the same domain and in many cases without the user even >> noticing (optional fields they wouldn't look at) >> * The passwords then get stored in our shared-secret fields clear text >> and available to all their peers >> * This can then be used for privilege escalation etc >> >> It seems like our only option is avoid use of password field at all >> and invent our own 'fake' password field to protect our users >> passwords from being exposed. That seems like a really disappointing >> solution. >> >> (Apologies in advance if this is completely off-list, I saw some >> threads leading to this list and it wasn't clear to me if this sort of >> discussion was acceptable). >> >> cheers, >> Dan
Received on Wednesday, 1 October 2014 23:49:06 UTC