Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Creative usernames and Spotify account hijacking

labs.spotify.com

Post reply on HN
Print view View original

21–30 of 83 posts

Re: Creative usernames and Spotify account hijacking

#21

Post by pilsetnieks »

jessaustin wrote: post #14
pilsetnieks wrote: post #4

I'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…

It looks to me as if the prevention of this caused more problems than it solved.

Re: Creative usernames and Spotify account hijacking

#22

Post by EvanKelly »

drivebyacct2 wrote: post #19
dan_manges wrote: post #7

Earlier quoted context omitted.

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"?

I don't think you're insensitive, but on a site which wants to foster users who care about their profile and persona on the site, freedom to display a username how they like could be a valuable feature.

Re: Creative usernames and Spotify account hijacking

#23

Post by drivebyacct2 »

So is there a need for a TRULY idempotent equivalent of XMPP's nodeprep? Or one that handles more Unicode points? Or is it a calculated decision to support Unicode 3.2 points only? (Sorry for the nooby questions, but this was very interesting and I don't know a lot about Unicode)

Re: Creative usernames and Spotify account hijacking

#24

Post by knome »

gkoberger wrote: post #12

Reminds 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: http://arstechnica.com/uncategorized/2006/01/6022-2/

That isn't a bug. Even the article you link notes that it is a feature, though they seem for some reason incredulous.

I've always liked that they do this on my accounts.

Re: Creative usernames and Spotify account hijacking

#25

Post by Maxious »

gkoberger wrote: post #12

Reminds 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: http://arstechnica.com/uncategorized/2006/01/6022-2/

The link agrees - it's a feature not a bug and one that considered security:

> As it turns out, even though Gmail will act as if there is no period in a username when delivering mail, it will not permit users to register accounts whose only difference to other account is a period. That is, if bob.jones is registered, bobjones cannot get an account (he could get bobjones2, obviously).

Re: Creative usernames and Spotify account hijacking

#26

Post by praseodym »

gkoberger wrote: post #12

Reminds 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: http://arstechnica.com/uncategorized/2006/01/6022-2/

You could (and still can) only register one of those addresses. Mail from the other two will be delivered to that address.

So, it's not a bug but rather a pretty nice feature: ever seen a handwritten email address with a period squeezed in there?

Re: Creative usernames and Spotify account hijacking

#27

Post by tmarthal »

duskwuff wrote: post #17
Esifer wrote: post #6

Why 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).

FYI, that all units measuring physical properties named after scientists use capitalized letters for their abbreviation[1]. So the ohm (named after Georg Ohm) is abbreviated as the uppercase omega, no idea why they are different unicode values, since they do not have different meanings.

Note that omega was probably used so that the 'O' wouldn't be confused with '0', e.g. 4O would be confusing, but 4Ω is not.

[1]The tesla is abbreviated 'T', joule is 'J', etc. etc.

Re: Creative usernames and Spotify account hijacking

#28

Post by TillE »

eli wrote: post #8
johnvschmitt wrote: post #2

This 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…

Easy to implement in a small project. Not so easy in a large enterprise project likely comprised of multiple interconnected systems.

Not a good excuse. There are plenty of enormous projects that provide only one basic interface to a bit of information. See every operating system API for examples.

Re: Creative usernames and Spotify account hijacking

#29

Post by mmahemoff »

dan_manges wrote: post #15
johnvschmitt wrote: post #2

This 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 So after they sent the password reset link, they called "fetchUserIdByName" again, but they passed in a username that had already…

If you're saying canonicalise(canonicalise(name)) is not the same as canonicalise(name), that's going to be seriously bug-prone. Idempotence ftw.

Re: Creative usernames and Spotify account hijacking

#30

Post by readme »

a-nikolaev wrote: post #13

I 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…

>They could simply store two names

Presumably you mean in the database? I don't see a reason to keep a copy of the lower() transformation of a string when it is incredibly cheap to transform a small string to lowercase.

What exactly is the point of that? I would just call lower() as needed, personally.

Post reply on HN