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

61–70 of 83 posts

Re: Creative usernames and Spotify account hijacking

#61

Post by drivebyacct2 »

lancestout wrote: post #50
drivebyacct2 wrote: post #23

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)

The decision to only support Unicode 3.2 is simply because the StringPrep framework [1] (which XMPP's nodeprep and various other protocols use) is forever tied to that version of Unicode. Current work is on the PRECIS framework [2] which uses the metadata for Unicode code points to determine how to handle them during canonicalization instead of relying on a hard coded set of mapping tables. There's still a lot of wor…

Great information, even cooler to see someone's got some code working alongside it, I might have to adapt it to Go if it's fairly reasonable to understand given my relative lack of experience with Unicode (heh as I'd mentioned and is probably obvious given your knowledge on hand).

Re: Creative usernames and Spotify account hijacking

#62

Post by timv »

brokenparser wrote: post #59
timv wrote: post #49

Earlier quoted context omitted.

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.

Well, in that case you're still storing it, you're just letting the the db store it for you.

But - when the issue here is the question of the reliability of the implementation of the canonicalisation function, having it done once in python, and then again by PG is going to be a huge issue.

Re: Creative usernames and Spotify account hijacking

#63

Post by a-nikolaev »

willvarfar wrote: post #56
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.

Yes, I agree that it sounds great. But, it does not mean that you really have to use this property. It was not necessary for the task, this is the point..

Well, in general, modular code should not make assumptions about other parts of the program (when possible).

You know, if the function is idempotent by definiiton, it does not mean that its implementation is. Unicode is changing too, new symbols are added.

Re: Creative usernames and Spotify account hijacking

#64

Post by Confusion »

tantalor wrote: post #52
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 inst…

  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.
If you write 'canonicalize(username)' in eight different places, you are not being DRY. If you need to write 'canonicalize(username)' in eight different places, your code probably doesn't separate responsibilities properly across separate modules.

As such, they have a lot to do with each other. After all, if you call code from more than one place, you are writing the calling code in more than one place. Lack of DRYness is about the fact that you are doing so. Lack af modularity is about why you need to do so.

Re: Creative usernames and Spotify account hijacking

#66

Post by antocv »

tantalor wrote: post #53

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.

Because they wanted "BigBird" to be the same as "bigbird" or "BIGBIRD". Hence if you wanted to rely on a userId, you would still need to ensure all the variations of BiGbirD map to the same userId.

Re: Creative usernames and Spotify account hijacking

#67

Post by robmcm »

NKCSS wrote: post #65

I think they could have handled the 'reward' a bit better :P "In this case the two users who posted to the forum where actually rewarded with some Spotify premium months." I'd say: Premium lifetime memberships would be better :)

Yeah, seeing as before they had the option to log into anyones account, affectivly the same as a lifetime membership.

Re: Creative usernames and Spotify account hijacking

#68

Post by oneeyedpigeon »

sleepyhead wrote: post #18
eli wrote: post #10

Earlier quoted context omitted.

Why does HTML have a and a tag?

is emphasis/semantic and is visual/style.

The parent was asking a rhetorical question, and drawing an analogy between the two: omega and ohm have different meanings, therefore it might be useful to be able to distinguish between the two. (Note that I say 'might'; when it comes to a character set, I'm not sure I 100% agree ...)

Re: Creative usernames and Spotify account hijacking

#69

Post by oneeyedpigeon »

drivebyacct2 wrote: post #60
willvarfar wrote: post #57

Earlier quoted context omitted.

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/creatio…

I don't think you were all wrong - there's a difference between username and name. My name has a space in it, but they won't allow me to represent that in the username. And if my name is already used by someone else as their username, I can't use it as mine. This doesn't bother me, so long as my name is displayed properly in the UI (if at all).

Re: Creative usernames and Spotify account hijacking

#70

Post by Sami_Lehtinen »

Nothing new at all, even my stockbroker had similar kind of bug. There should be only one function which handles usernames. When same thing is implemented differently all over the source, this is exactly what happens.

I have seen also much worse solutions. Where actually giving username, logs you in (sets logged in session cookie) and then prompts for password. When you enter invalid password you're logged out. If you give username, and then change url, you're in. Business as usual. When you test it, it works. Username + right password = ok, Username + wrong password != ok. Tests passed, and that's it.

Post reply on HN