[deleted]
Creative usernames and Spotify account hijacking
11–20 of 83 posts
Re: Creative usernames and Spotify account hijacking
#12Reminds me of the early GMail bug, where you could sign up with "john.smith", "jo.hn.smi.th" or "johnsmith", but all mail was delivered to the period-less version:
Re: Creative usernames and Spotify account hijacking
#13I don't see any real reason to rely on idempotence.
They could simply store two names: One is provided by the user (verbatim), and the second is its reduction to lowercase letters and digits (canonical). For all internal logic, they could use only the canonical name, and use the verbatim name in the front-end to make the user happy.
> Lower casing has the key property of being idempotent, i.e., that applying it more than once has no effect: x.lower() == x.lower().lower(). So if a username gets passed from service to service and you want to make sure it is in canonical form you can safely apply .lower() and if it was already in canonical form there is no harm done, and it is easy to stay safe.
Apparently, they thought that it's ok to use verbatim and canonical names interchangeably, relying on idenpotence property of the XMPP function.
It looks like a huge design error.
Re: Creative usernames and Spotify account hijacking
#14I'm confused about why they even had the need for canonicalising the usernames for whatever purpose? Why couldn't they just have stored and used them just as they are?
If they did as you suggest, the specific account-stealing flaw they had wouldn't happen, but since many unicode points have very similar glyphs, there would still be "copycat" accounts. That is, the strings "Oscar" and "Οscar" appear very similar (if one has the proper fonts installed), and one user could therefore pose as another.
It's true that many sites don't care about this, but I don't fault Spotify for trying to prevent it.
Re: Creative usernames and Spotify account hijacking
#15This seems odd. I mean, if their code was properly modular , they would have just one place where they "fetchUserIdByName(userName)", which returns one user ID or null if it's not used yet. When a new user is created, it then gets assigned a unique user ID. The email address is assigned to that user ID. Then, if they do a password reset on user = "bigbird", it should do the exact same lookup to find the email address…
Based on their description of the bug, it sounded like the code was modular, but they called the function twice: once when the password reset request was generated, and again when the link in the email was clicked.
However, when the link was used, canonical_username was once again applied
Re: Creative usernames and Spotify account hijacking
#16Why does Unicode threat Omega and Ohm like different characters?
Because one is a greek letter, and the other is a unit of resistance. The fact that they're represented by the same symbol is irrelevant.
Re: Creative usernames and Spotify account hijacking
#17Why does Unicode threat Omega and Ohm like different characters?
Because they have rather different meanings. Capital omega (Ω, U+03A9) is a Greek letter, with the lower-case form ω; ohm (Ω, U+2126) is a symbol used in electrical engineering with a related symbol "mho" (℧, U+2127).
Re: Creative usernames and Spotify account hijacking
#18Re: Creative usernames and Spotify account hijacking
#19I'm confused about why they even had the need for canonicalising the usernames for whatever purpose? Why couldn't they just have stored and used them just as they are?
They gave one reason in the post. They wanted usernames to be case insensitive, so that if there's a user named BigBird, somebody else can't sign up as bigbird. Case insensitive usernames are also helpful to minimize support issues when somebody forgets the exact case they used when they created their account.
Am I insensitive in wondering "Why not just limit it to lowercase, ASCII chars"?
Re: Creative usernames and Spotify account hijacking
#20This seems odd. I mean, if their code was properly modular , they would have just one place where they "fetchUserIdByName(userName)", which returns one user ID or null if it's not used yet. When a new user is created, it then gets assigned a unique user ID. The email address is assigned to that user ID. Then, if they do a password reset on user = "bigbird", it should do the exact same lookup to find the email address…
This is what I thought at first. If it's the exact same check (which it should be), why is there any possibility of the answer being different? But the real "bug" here is that they were treating the canonicalized username as if it were just as good as the original username, which is only true if the adjustment function is idempotent as they say.
Another possible solution would be to assume the username given to the password reset form is already canonicalized (which would be necessarily true, as far as I understand).
EDIT: However this wouldn't solve the other bug that's been discovered here, which is that "ᴮᴵᴳᴮᴵᴿᴰ" is canonicalized differently than "BIGBIRD", thus defeating the purpose of canonicalization (for that particular case) in the first place.