Unicode character bits thrown away
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
PySGP |
Triaged
|
High
|
Unassigned |
Bug Description
This is a bug in the original SuperGenPass implementation (http://
When SGP processes the salted string, it bitwise-ands each character's Unicode code point with 0xFF (I'm not sure if this was their intention). This means it's throwing away some information from the string - all but the lowest 8 bits of each character. This is a (minor) potential security vulnerability, as all strings with the same low 8 bits in each character will generate the same password.
To demonstrate, try sgp(passwd="foo", url="google.com").
With the master password "foo" (code points U+0066, U+006F, U+006F), you get "mSp9jooep2".
Now try the password "fůo" (code points U+0066, U+016F, U+006F). "mSp9jooep2".
Or even "Ѧůᑯ" (code points U+0466, U+016F, U+146F). "mSp9jooep2".
(ie. any characters where the last two hex digits are the same => same hash).
This is not very practical to exploit, but there is a small potential, IF unicode is allowed in domain names (which it currently isn't ~really~ but you sort of can, and will probably be in the future). I could create a site at "gůůgle.com" (try it) which will generate the same password as your login for google.com. If I assume you're using this algorithm, I can steal your Google password.
Not sure why you'd trust a site called "gůůgle.com", it's clearly a phishing site, but some people might.
Source Code Location
This "bug" is implemented in the function str2binl in supergenpass.py, and clearly marked in comments.
Plan For Fix
The correct behaviour would be to encode the string to UTF-8 first. I suspect this wasn't done originally because JavaScript has no built-in way to do this. Note that fixing it this way would also make it easier to port the algorithm to other languages which don't support Unicode at all, such as PHP and C.
I doubt you could fix this without breaking the algorithm for anybody who happens to have used Unicode in their password. An alternative version could be made with the correct behaviour, but it would have to be marked as incompatible. To be discussed.
Changed in pysgp: | |
importance: | Undecided → Wishlist |
status: | New → Confirmed |
This bug has been fixed in SuperGenPass 2.0 -- now live.
I stumbled upon this project by accident, and this was the first I'd heard of this bug. Wish you'd sent it to me, I would have fixed it much sooner.