Yubico Forum

I set my password to 'naïve' in the Android Yubico Authenticator app.

The python yubico-authenticator crashes now; it doesn't seem to support asking for a password at all:


Even if I fix that up and manually hard-code the password to "na\xc3\xafve" (because Python is horrid and I can't just type it), it doesn't work. It looks like "na\xefve" *does* work, implying that the Android app actually converted to a legacy 8-bit character set like ISO8859-1, which would be horridly wrong.

Please clarify the documentation at https://developers.yubico.com/ykneo-oath/Protocol.html to make it clear that the password has to be treated as UTF-8 (which is the only sensible choice), and fix the Android and python apps accordingly.

Thanks.

Update:
I used the python tool to create a credential with the name 'rôle ♥ foo'. It does appear to create it as UTF-8, perhaps purely because I'm running in a 21st century environment; if I was running with a legacy charset then I assume no conversion would be done. It displays correctly in the Android app too, implying that the Android tool *is* doing the right thing for credential names, if not passwords.

Unfortunately, the python app *displays* the credential in question as 'rôle ♥ foo', having failed to be consistent even within itself.

Check last commit do you still have issues?

Works well on my windows 8.1 & nexus 5 with Swedish àù'äöååååå passwords...

_________________
-Tom

There is no visible improvement. It still crashes instead of asking for a password, with the same error "'self' is not defined".

If that dialog did actually work, I assume it would return a password entered by the user, in the locale-configured character set (which should be UTF-8 for any modern system anyway). But if I was running on a legacy system with non-UTF8 locale, then the new commit does look like it would convert the password into UTF-8 before trying to use it. So that's nice.

But the Android app is broken too, and is using something like ISO8859-1 on the device — which is why a hardcoded password of "na\xefve" works after I use the Android tool to set the password to "naïve", when the hardcoded password *should* be "na\xc3\xafve". If I try to use Android to set the password to "♥" (U+2665) I have no idea what *actually* gets set; I haven't managed to work it out.

Is there a corresponding update to the Android app to fix things there?

And there's also the display issue of credentials whose name is non-ASCII...

Try with the latest commit 574642a0e773cf2782c9689ded033bd5c0cf2a34
https://github.com/Yubico/yubioath-desktop

_________________
-Tom

Commit 574642a0 fixes the 'rôle ♥ foo' key to display properly; thanks.

That just leaves the crash when prompting for password, and the misbehaviour of the Android app.

Oh, and the fact that you need to call SCardBeginTransaction() / SCardEndTransaction(), and reselect the ykneo-oath applet, each time you talk to the device. Currently if anything else talks to the Yubikey the yubico-authenticator app stops working.

I've started looking into the issue for the android app, and I think the problem is in Android: http://android-developers.blogspot.se/2013/12/changes-to-secretkeyfactory-api-in.html

According to the link, it should correctly handle unicode characters in passwords in 4.4 (KitKat) and later. Can you confirm that you're running an older version of Android (otherwise my theory goes out the window)?

In November it won't have been Kit Kat. I do have Kit Kat now and can test both. It sounds like they *shouldn't* interoperate, right?

It sounds like the workaround for older Android is to take each byte of the UTF-8 byte stream and treat it as a Unicode code point (which is basically the same as converting from ISO8859-1), then use *that* as the input to the broken PBKDF2WithHmacSHA1 function.

So if you start with a passphrase of "naïve ♥", that looks like this in UTF-8:
6e 61 c3 af 76 65 20 e2 99 a5

If you interpret those bytes as ISO8859-1, you get
U+006E U+0061 U+00C3 U+00AF U+0076 …
or "naïve ♥".

That string, if passed to the broken PBKDF2WithHmacSHA1 function, should generate the correct result. AIUI.

That assumes you want to switch to using the sane representation, of course. Since Android already switched its default PBKDF2WithHmacSHA1, you already *have* a compatibility problem, with passphrases set on KK doing one thing and older versions another. I suspect you might do best to *try* both for unlocking, and always use the fixed version when setting a passphrase.

OK, setting passwords with KK works properly, modulo a little confusion about precisely *which* Unicode heart Android has accessible via its keyboard. It's U+2661 WHITE HEART SUIT, and not U+2665 BLACK HEART SUIT which I usually use for torture testing. I can now interoperate happily between KK and OpenConnect.

I can also interoperate with the older Android. I tried setting a password of "¿", which in UTF-8 is bytes c2 bf. The way to get the older Android to use those bytes is to tell it the password is U+00C2 U+00BF, or "¿". As long as I actually type those correctly (unlike in the original, unedited version of this post), that works too.

So I think I'm going to modify the OpenConnect code so that if authentication fails, *and* if the passphrase has non-ASCII characters in it, it'll try the low 8 bits of each character as the old Android does.

My recommendation would be to make the Android app do the same. On KK that means trying the old PBKDF2WithHmacSHA1And8bit function to authenticate, if PBKDF2WithHmacSHA1 fails.

On older Android, you actually want to *start* by converting the UTF-8 byte representation of your passphrase from ISO8859-1, as described above, and using *that* as the input to the broken PBKDF2WithHmacSHA1. Which is just working around the brokenness that's fixed in KK. Use that when setting passphrases, and for the first attempt at authenticating. If authenticating with that fails, *then* just pass the original passphrase to the broken PBKDF2WithHmacSHA1 and try that.

Diff available here: https://github.com/Yubico/yubioath-andr ... bbf095d8de

I'm going to do some more testing after lunch, but so far it seems to do the trick.

Mine is here: http://git.infradead.org/users/dwmw2/op ... ff/9a7acca