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

51–60 of 83 posts

Re: Creative usernames and Spotify account hijacking

#51

Post by gwright »

readme wrote: post #30
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.

If you are testing for uniqueness of the canonical name you don't want to have to recompute the canonical name for all your existing records.

Re: Creative usernames and Spotify account hijacking

#52

Post by tantalor »

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…

What you're talking about has nothing to do with modularity. You're thinking of DRY. They having nothing to do with each other.

DRY tells us the code for looking up a user id by user name should be written in only one place, not that the code should be called from only one place.

The mistake was assuming the name->name function was idempotent, because it wasn't.

You are right to suggest using a name->id function instead. It would not suffer the same problem because the canonical name should not be stored... it's an implementation detail!

Re: Creative usernames and Spotify account hijacking

#53

Post by tantalor »

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.

Why?

Suppose you only pass the original name around instead. Then you don't require your canonicalization function to be idempotent, which might be good in your case since it wasn't.

Re: Creative usernames and Spotify account hijacking

#54

Post by tantalor »

brown9-2 wrote: post #44
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…

Sounds like they are using the username as the key in their DBs, which sounds like the ultimate case of any pain: Could the method for computing canonical usernames based on nodeprep.prepare() be salvaged? If not we would be in trouble since we use canonical usernames in various databases so that changing how to derive them in a non-backwards compatible way would be quite costly.

Not necessarily. It their canonicalization function were idempotent (e.g., the identity), then this database scheme would work well.

How else do you map username to user id?

Re: Creative usernames and Spotify account hijacking

#55

Post by mzl »

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

Yes, because lowercase ASCII does not meaningfully capture how names are written in most of the world. If you want to cater to a global audience, it is simply not sufficient.

Re: Creative usernames and Spotify account hijacking

#56

Post by willvarfar »

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…

Canocialisation functions are, by definition, idempotent.

Their canocialisation function, which is a standard one, was broken by subtle changes in Python 2.5, but worked previously.

Re: Creative usernames and Spotify account hijacking

#57

Post by willvarfar »

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

As they say in the article, they are trying to serve a global audience. As is easily googlable, Spotify was developed in the Baltic; the developer's own names likely contain non-ASCII characters.

Re: Creative usernames and Spotify account hijacking

#58

Post by brokenparser »

jzwinck wrote: post #32
TillE wrote: post #28

Earlier quoted context omitted.

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.

How about the API to allocate memory in Windows? VirtualAlloc: http://msdn.microsoft.com/en-us/library/windows/desktop/aa36... VirtualAllocEx: http://msdn.microsoft.com/en-us/library/windows/desktop/aa36... VirtualAllocExNuma: http://msdn.microsoft.com/en-us/library/windows/desktop/aa36... It all started out nice and clean I'm sure, but within a few years you start to see many more than one basic interface to some th…

And {Global,Heap,Local}{,re}{Alloc,Free,Lock,Unlock}. 4 sets of APIs just to allocate memory. Although Local* and Global* are mapped to Heap for a while now and (IIRC) (un)lock functions don't do anything (but they used to). This BC is still required today.

Re: Creative usernames and Spotify account hijacking

#59

Post by brokenparser »

timv wrote: post #49
readme wrote: post #43

Earlier quoted context omitted.

I think the act of storing both names is bad, because you multiply the amount of data that could possibly become wrong by 2. With lower(), we can expect we'll get the right transformation of string A each time. If instead, we store string A, and then store string B as A.lower() and copy it... A.lower() will always be A.lower, but it's much easier for someone to come along, screw with the database, and change B.

I'm not sure how they can avoid storing both. They need to store the verbatim username in order to know how to display the username in the UI. They need to store the canonical username in order to efficiently know whether a given canonical username is in use.

Not necessarily, in PostgreSQL you could simply add a canonicalised index.

Re: Creative usernames and Spotify account hijacking

#60

Post by drivebyacct2 »

willvarfar wrote: post #57
drivebyacct2 wrote: post #19

Earlier quoted context omitted.

Am I insensitive in wondering "Why not just limit it to lowercase, ASCII chars"?

As they say in the article, they are trying to serve a global audience. As is easily googlable, Spotify was developed in the Baltic; the developer's own names likely contain non-ASCII characters.

Interesting, I felt foolish about an hour after having written this post, realizing that in most scenarios, it really shouldn't ever be any amount of effort minus half a second of planning and felt foolish for writing off unicode. (Normally I go the other route, unicode all the things).

I suppose I feel that I was probably right to call myself arrogant then, to find out what you noted about Spotify's creators/creation. Interesting, thanks for the perspective check

Post reply on HN