av8rgeek wrote:
Does this limited character set necessarily make the generated string any less secure? Why does it not use a larger set of characters?
This is a very important question, and I think it should be addressed in the Wiki. Maybe I'll work up a page for it based on this post and others I've done.
First of all, the question of character length doesn't matter at all in OTP mode, because the information emitted by the yubikey is not a password, but merely some encrypted information. The number of characters emitted simply needs to be long enough to communicate the ID and current state of the yubikey. The state is AES encrypted by a secret known only inside the key and to the server. It's not a "password", and thus the length has nothing whatsoever to do with the security of the OTP system. In other words, no, it's not less secure at all.
Now, your question actually becomes more interesting for static passwords, where the emitted string is in fact the secret itself. So let's talk about static mode. It's understandable to have the misconception that a smaller character set means less security, if you are thinking about a password as some fixed number of characters. Instead, to learn the amount of security of a password we need to consider "number of bits" encoded.
The yubikey can store and emit a static password with up to 256 bits of complexity (if you use the
right tool). It emits this using the modhex language. Each character encodes 4 bits of the total password. This is how your intuition was telling you the limited character set decreased security; you were comparing some fixed number of characters in modhex versus the same number of characters in ASCII.
But whether a certain password is encoded as 64 modhex characters using the limited modhex set, or 32 ascii characters, it doesn't make a difference to the security represented by that password. You could even represent it using a binary alphabet of 2 characters (say 0 and 1) and in that base-2 language the password would take 256 characters to say. But still it has the same amount of security no matter what character set you use. It just gets "longer" or "shorter".
Easy when you think about it that way, right?
Now, here's one wrinkle you need to be aware of... Most apps you use that require a password will be ASSUMING that you are using the full set of ascii characters in your static password composition. So, apps that tell you the security level of your password may over-estimate it as being twice as strong as it really is: 512 bits instead of the real 256. (256 bits is INCREDIBLY strong for a static password by the way).
Similarly, apps that limit you to a certain number of characters of input are less secure. If an app limits you to 40 characters, and you choose to use a yubikey static password, then you are only getting 40*4 = 160 bits of password complexity. If you created a completely random ASCII password you could have 40*8 = 320 bits of password complexity.
Lastly, some apps that make the "ASCII assumption" will tell you that you need to use digits and "special" characters to make the password secure. This is because they assume you are using a short human-memorable password that encodes a small amount of bits and could be easily brute-force guessed. Since you are in fact using a super long 256-bit password, this is not the case. But to make these apps happy, you may have to manually prepend a short sequence of "special" ascii characters before tapping the yubikey.
And that can be a good thing, too: In general, having the static password comprised of something in your head in addition to something in the yubikey is more secure, because an attacker who steals your key cannot then immediately possess your entire password. This split method is of course no protection against key logging, since the password is ultimately still static in nature.
Login
FAQ
Search
