Re: Unicode in passwords

They demand such passwords only for their web services, which are accessed by web browsers. Not for booting devices. Being on the web, the protocols are based on HTML and web browsers. As the web is now Unicode with UTF-8 in a vast majority of contents, those web services are already UTF-8 ready

RE: Unicode in passwords

Philippe Verdy wrote: > They demand such passwords only for their web services, which are > accessed by web browsers. Not for booting devices. My company enforces all of the password restrictions I listed, as well as "ASCII only," for access both to individual PCs and to the company network. --

Re: Unicode in passwords

seem (when I see them logging in to give presentations) to have long passwords - 20-30 characters - and they don't seem to have a problem. This also illustrates why defaulting to hidden passwords is useful. > Biometric identification is also another fake security (because it is Not sure what this ha

Re: Unicode in passwords

2015-10-07 13:16 GMT+02:00 Stephane Bortzmeyer : > On Tue, Oct 06, 2015 at 10:53:00PM +0200, > Philippe Verdy wrote > a message of 72 lines which said: > > > it is highly preferable to extend the character repertoire to > > Unicode and accept letters in

Re: Unicode in passwords

On Tue, Oct 06, 2015 at 10:53:00PM +0200, Philippe Verdy wrote a message of 72 lines which said: > it is highly preferable to extend the character repertoire to > Unicode and accept letters in NFKC form and unified by case folding As I said before, "the ship has sailed".

Re: Unicode in passwords

Philippe Verdy wrote: > This is a demonstration that using case differences to add more > combinations in short passwords is a bad design. But more and more organizations and banks and supermarket rewards programs are demanding it, along with "at least one digit" and "at least one 'special'

Re: Unicode in passwords

On Tue, 6 Oct 2015 11:21:42 +0200 Mark Davis ☕️ wrote: > While I think that RFC is useful, it has been interesting just how > many of the problems recounted on this list go far beyond it, often > having to do with UI issues. It would be useful to have a paper > somewhere that

Re: Unicode in passwords

2015-10-06 21:57 GMT+02:00 Richard Wordingham < richard.wording...@ntlworld.com>: > It's an interesting issue for a password that one can't type. It's by > no means a guarantee, either. I once specified a new a password that > changed case in the middle not realising that I had started with

Re: Unicode in passwords

On Tue, 6 Oct 2015 20:13:12 +0100 (BST) Julian Bradfield wrote: > On 2015-10-06, Asmus Freytag (t) wrote: > > All browsers I use display spaces in input boxes, and put blobs for > > hidden fields. Do you have evidence for broken input fields?

Re: Unicode in passwords

2015-10-06 16:31 GMT+02:00 Julian Bradfield : > On 2015-10-06, Philippe Verdy wrote: > > I don't think it is a good idea for tectual passwords to make differences > > based on the number of spaces. Being plain text they are likely to be > > displayed

Re: Unicode in passwords

On Tue, Oct 06, 2015 at 12:57:51PM +0900, Yoriyuki Yamagata wrote a message of 33 lines which said: > FYI, IETF is working on this issue. See Internet Draft > https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-17 based > on PRECIS framework RFC 7564

Re: Unicode in passwords

On 2015-10-06, Asmus Freytag (t) wrote: > All browsers I use display spaces in input boxes, and put blobs for > hidden fields. Do you have evidence for broken input fields? > > > Network keys. That interface seems to consistently give people a > choice

Re: Unicode in passwords

While I think that RFC is useful, it has been interesting just how many of the problems recounted on this list go far beyond it, often having to do with UI issues. It would be useful to have a paper somewhere that organizes all of the problems presented here, and maybe makes a stab at describing

Re: Unicode in passwords

On 2015-10-06, Philippe Verdy wrote: > Finally note that passwords are not necessarily single identifiers > (whitespaces and word separators are accepted, but whitespaces should > require special handling with trimming (at both ends) and compression of > multiple occurences.

Re: Unicode in passwords

I don't think it is a good idea for tectual passwords to make differences based on the number of spaces. Being plain text they are likely to be displayed in utser interfaces in a way that the user will not see. Without trimming, users won't see the initial or final space, and the password input

Re: Unicode in passwords

And there are severe issues in this RFC for its case mapping profile: it requires converting "uppercase" characters to "lowercase", but these properties are not stable (see for example the history of Cherokee letters, changed from gc=Lo to gc=Lu when lowercase letters were added and with case

Re: Unicode in passwords

Note that Java strings DO allow the presence of lone surrogates, as well as non-characters , because Java strings are unrestricted vectors of 16-bit code units (non-BMP characters are handled as pairs of surrogates). In those conditions, normalizing the Java string will leave those lone

Re: Unicode in passwords

> On Oct 6, 2015, at 6:04 , Philippe Verdy wrote: > > In those conditions, normalizing the Java string will leave those lone > surrogates (and non-characters) as is, or will throw an exception, depending > on the API used. Java strings do not have any implied encoding

Re: Unicode in passwords

On 10/6/2015 7:31 AM, Julian Bradfield wrote: All browsers I use display spaces in input boxes, and put blobs for hidden fields. Do you have evidence for broken input fields? Network keys. That interface seems to consistently give people a choice

Re: Unicode in passwords

On 2015-10-06, Philippe Verdy wrote: > I don't think it is a good idea for tectual passwords to make differences > based on the number of spaces. Being plain text they are likely to be > displayed in utser interfaces in a way that the user will not see. Without This is true

Re: Unicode in passwords

said: > > > You really wouldn’t want “Schlüssel” and “Schlüssel” being different > > passwords, would you? (assuming that my mail client and/or OS is not > > interfering, the first is NFC, while the second is NFD) > > Hence the RFC 7613, mentioned already here by Marc Blanche

Re: Unicode in passwords

; You really wouldn’t want “Schlüssel” and “Schlüssel” being different >> > passwords, would you? (assuming that my mail client and/or OS is not >> > interfering, the first is NFC, while the second is NFD) >> >> Hence the RFC 7613, mentioned already here by Marc Blanchet, th

Re: Unicode in passwords

On 2015/10/01 13:11, Jonathan Rosenne wrote: For languages such as Java, passwords should be handled as byte arrays rather than strings. This may make it difficult to apply normalization. Well, they should be received from the user interface as strings, then normalized, then converted to

Re: Unicode in passwords

f *Clark S. Cox III *Sent:* Thursday, October 01, 2015 2:16 AM *To:* Hans Åberg *Cc:* unicode@unicode.org; John O'Conner *Subject:* Re: Unicode in passwords On 2015/09/30, at 13:29, Hans Åberg <haber...@telia.com> wrote: On 30 Sep 2015, at 18:33, John O'Conner <jsocon...@gmail.co

Re: Unicode in passwords

Dear John, FYI, IETF is working on this issue. See Internet Draft https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-17 based on PRECIS framework RFC 7564 https://tools.ietf.org/html/rfc7564 Best, > 2015/10/01 1:33、John O'Conner のメール： > > I'm researching

Re: Unicode in passwords

On 5 Oct 2015, at 8:14, Shriramana Sharma wrote: I recently came across this bug report where a filesystem encrypted with a Cyrillic script password could not be decrypted at boot time: https://bugzilla.redhat.com/show_bug.cgi?id=681250 And? From what I understand, this is related to the

Re: Unicode in passwords

I recently came across this bug report where a filesystem encrypted with a Cyrillic script password could not be decrypted at boot time: https://bugzilla.redhat.com/show_bug.cgi?id=681250 -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Unicode in passwords

I had hoped it would be obvious my reply was not intended to the "best practices" part of the OP, but to the "potential problems" part of it... In any case, I have nothing further to say on this topic. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Unicode in passwords

On 5 Oct 2015, at 9:42, Shriramana Sharma wrote: On 10/5/15, Marc Blanchet wrote: On 5 Oct 2015, at 8:14, Shriramana Sharma wrote: https://bugzilla.redhat.com/show_bug.cgi?id=681250 And? Well the OP did say: I'm researching potential problems and best

Re: Unicode in passwords

On 5 Oct 2015, at 10:47, Shriramana Sharma wrote: I had hoped it would be obvious my reply was not intended to the "best practices" part of the OP, but to the "potential problems" part of it... sure. my comment was also just informative, not targeting to your comment, but targeting the fact

Re: Unicode in passwords

On 10/5/15, Marc Blanchet wrote: > On 5 Oct 2015, at 8:14, Shriramana Sharma wrote: > >> https://bugzilla.redhat.com/show_bug.cgi?id=681250 > > And? Well the OP did say: I'm researching potential problems and best practices for password policies that allow

Re: Unicode in passwords

he first is NFC, while the second is NFD) Hence the RFC 7613, mentioned already here by Marc Blanchet, that you must really read if you're interesed in Unicode passwords. In that case, the RFC is clear: NFC mandatory (and UTF-8 encoding). 4. Normalization Rule: Unicode Normalization Fo

Re: Unicode in passwords

On Thu, 1 Oct 2015 07:01:12 +0200 Mark Davis ☕️ wrote: > I've heard some concerns, mostly around the UI for people typing in > passwords; that they get frustrated when they have to type their > password on different devices: > >1. A device may not have keyboard mappings

Re: Unicode in passwords

> On 1 Oct 2015, at 07:19, Marc Durdin wrote: > > 2. The number of dots corresponds to the number of code points, which > is misleading with complex scripts or advanced input methods: you won’t > necessarily see one dot per keystroke; in some cases, typing a character

Re: Unicode in passwords

As to #1, my note needs some clarification. For characters that don't typically occur on *any* keyboards, people don't typically use those in their passwords, so switching between different devices doesn't matter. (One caveat would be where the password dialog permits selection from a palette.

Re: Unicode in passwords

On 1 Oct 2015, at 08:33, Richard Wordingham wrote: > > Even ASCII can have problems. A password containing '#' and '|' can't > be entered when a physical US keyboard (102 keys) is interpreted using > a mapping for a British keyboard (103 keys). (There seem to be > different conventions as to

Re: Unicode in passwords

> On 30 Sep 2015, at 18:33, John O'Conner wrote: > > Can you recommend any documents to help me understand potential issues (if > any) for password policies and validation methods that allow characters from > more "exotic" portions of the Unicode space? On UNIX

Re: Unicode in passwords

On Wed, 30 Sep 2015 16:15:30 -0700 "Clark S. Cox III" wrote: > You really wouldn’t want “Schlüssel” and “Schlüssel” being different > passwords, would you? It'd make them slightly safer to write down! I trust the tradition of truncating Unix passwords to 8 bytes is well

RE: Unicode in passwords

To: Hans Åberg Cc: unicode@unicode.org; John O'Conner Subject: Re: Unicode in passwords On 2015/09/30, at 13:29, Hans Åberg <haber...@telia.com> wrote: On 30 Sep 2015, at 18:33, John O'Conner <jsocon...@gmail.com> wrote: Can you recommend any documents to help me understa

Re: Unicode in passwords

On 30 Sep 2015, at 12:33, John O'Conner wrote: I'm researching potential problems and best practices for password policies that allow non-Latin-1 Unicode characters. My searching of the unicode.org site showed me a general security considerations document (UTR #36) but nothing specific for

RE: Unicode in passwords

icode.org> Subject: Re: Unicode in passwords I've heard some concerns, mostly around the UI for people typing in passwords; that they get frustrated when they have to type their password on different devices: 1. A device may not have keyboard mappings with all the keys for their language. 2.

Re: Unicode in passwords

t; *Cc:* unicode@unicode.org; John O'Conner > *Subject:* Re: Unicode in passwords > > > > > > On 2015/09/30, at 13:29, Hans Åberg <haber...@telia.com> wrote: > > > > > > On 30 Sep 2015, at 18:33, John O'Conner <jsocon...@gmail.com> wrote: &g