Its not the idea of not having unique usernames thats in question here...its the hypothetical implementation thats, for lack of a better word, retarded.

6/20/2009 9:34:33 PM

You were initially incoherent and continue to reflect a poor comprehension of what I'm suggesting. I hope it doesn't offend you when I say that I haven't put a lot of stock into your thoughts or ideas on the matter, and don't intend to.

6/20/2009 9:49:33 PM

lol nice trolling, I'm taking notes

6/20/2009 10:07:43 PM

Hurry up and start that other thread. I'm really anxious to see what kind of hypothetical applications you can come up with that would benefit from shared usernames on any level.

6/20/2009 10:15:33 PM

Quote :

"You were initially incoherent and continue to reflect a poor comprehension of what I'm suggesting. I hope it doesn't offend you when I say that I haven't put a lot of stock into your thoughts or ideas on the matter, and don't intend to."

I loled. Maybe if you put as much thought into your idea as you did this last post you wouldn't sound like a complete fucktard. On second thought, never mind you would.

And I'd also like to add that I don't think you know what incoherent means.

[Edited on June 20, 2009 at 10:20 PM. Reason : .]

6/20/2009 10:19:13 PM

I'm going to assume,Tiberius, you were just trolling or high or something and that a detailed explanation of your post's retardedness is unnecessary

[Edited on June 20, 2009 at 11:02 PM. Reason : asdfsdf]

6/20/2009 11:01:55 PM

Quote :

"And I'd also like to add that I don't think you know what incoherent means."

Quote :

"that is a really dumb idea to match passwords and usernames for uniqueness. If you really wanted multiple usernames then you would match them to emails not passwords...lol"

I would describe this post as incoherent. I don't want to drop a dictionary on you, I assume you can pull it up and cross-reference.

Quote :

"Hurry up and start that other thread. I'm really anxious to see what kind of hypothetical applications you can come up with that would benefit from shared usernames on any level."

I already listed several. In fact, I said a lot of things that I don't think anyone has read or thought through, that's why ...

Quote :

"I'm going to assume,Tiberius, you were just trolling or high or something and that a detailed explanation of your post's retardedness is unnecessary"

... I'm not really bothering to respond with substance anymore. I've yet to see a post that responds concretely to either the technical aspects (which, as I've said, I'm not really interested in discussing as I don't really value random TWW web developers opinions' on security), or the intended goal.

Quote :

"and also if I try to use the password stupid and it returns "password strength sucks" but idiot works then I'm going to assume that stupid was someone else's password with the same username because obviously idiot isn't any stronger"

The purpose of a password strength requirement is essentially to reduce the probability of a collision whether or not the username is shared. With adequate password strength requirements both an intentional and unintentional collision would nearly as improbable as a successful brute force attack with a known username. In the case of a malicious user sharing the name of his target, I'm pretty sure the probability is identical minus the one known password. Feel free to demonstrate otherwise. There is marginally more exposure in the unintentional collision case, yes, but I really don't see it as being a fatal flaw with adequate password strength requirements. I believe the case of a random username and password colliding with another username of the same password is equivalent to the birthday problem except with very, very long years. At least one unintentional collision is very likely, but a large number of collisions is not, and intentional collisions are not. The effect on brute force probabilities without a desired target has already been discussed in a previous post.

[Edited on June 20, 2009 at 11:44 PM. Reason : .]

6/20/2009 11:36:39 PM

^

do you not think people would intentionally test passwords that resulted in low security strength to crack other peoples accounts?

If there are 10,000 accounts named "Sarah" it can't be that hard to run a dictionary attack against it and find at least one match

P.S. It would make it much more convenient for malicious users, instead of running attacks on an email address, they get to try against thousands of users at once! Brilliant!

[Edited on June 20, 2009 at 11:43 PM. Reason : l]

6/20/2009 11:40:44 PM

Hey: check my edit and consider the probabilities of the events you're proposing to be fatal flaws before you suggest they're fatal flaws. I did it before I posted the original comment, which is why I find this clueless bullshit tiresome.

If there are 10,000 accounts named "Sarah", then the username "Sarah" should have a password length requirement 2 characters longer than an unshared username for the probability of brute force success to be roughly the same, if you assume roughly 100 characters are permissible in the password. THIS WAS ADDRESSED ON THE FIRST PAGE YOU ILLITERATE COCKSUCKING SACK OF STUPID.

Anyway, I'm done with this for real unless someone with a clue has anything to add. I apologize for shitting up this thread, I should have made a second thread for this it seems.

[Edited on June 20, 2009 at 11:51 PM. Reason : .]

6/20/2009 11:45:59 PM

Consider the case of Facebook under your conditions:

1.) 10,000 people with the username "Sarah"
2.) One of them is at least a dumbass and sets their password to "password"

Are you telling me that no one else is able to use the word "password" as a valid password? If not, ok, but still, anytime someone tries to log in as a "Sarah," what keeps them from trying out stupid passwords like this on their account?

Also, the possibility of a brute force attack is greater when you are trying against a base of 10,000 "Sarahs" as opposed to individual email addresses.

Instead of taking this personally, try to explain how it is possible that the above will never be an issue.

6/20/2009 11:54:49 PM

Do you even know what a password strength requirement is? It typically involves a dictionary word check, which rules out every counter argument that has been proposed so far without further discussion. It involves character class requirements, which further reduces the probability of a collision. It finally involves a password length requirement, which as I've stated can be variable to reduce the exposure to brute force as necessary, or it can be of static length large enough to provide a low probability of collision in highly shared usernames to the desired rate.

Quit dragging me back into this dumb ass argument unless you've got an equation that illustrates a highly probable failure scenario which can occur in a malicious context. Note that the "birthday problem" equivalence I noted earlier has pretty much no relevance in malicious contexts.

[Edited on June 21, 2009 at 12:08 AM. Reason : I really don't want to have to do math to prove a point I never considered open for discussion]

6/21/2009 12:01:15 AM

Quote :

"Quit dragging me back into this dumb ass argument unless you've got an equation that illustrates a highly probable failure scenario which can occur in a malicious context."

This confirms it. You have to be trolling now.

6/21/2009 12:10:46 AM

Sometimes it's cool to admit you had a dumb idea.

I see this is not one of those times.

6/21/2009 12:15:51 AM

Fine, I'll do some fucking math.

Let's say the character space is 54 characters. I picked it random, substitute your own if you like, it's usually larger.

Let's say the length requirement is 12.

Without shared usernames the probability of a collision when attacking a fixed username is 1 / 54^12:
.000000000000000000001626577955

With a username shared by 10,000 users ( * 10000):
.000000000000000016265779550000

With password length increased by 3, still shared by 10000 users ( * 1 / 54^3):
.000000000000000000000103298401
-- 106,581,410 petabytes of password data alone must be transmitted to guarantee a collision.

Even without compensating, with a password length requirement of 12 it's already pretty much never going to happen on a remote access system.

With a more typical password length requirement of 8:
.000000000000013830883443250585 - unshared username
.000000000138308834432505850000 - shared username
-- 74.505806 gigabytes of password data alone must be transmitted to guarantee a collision.
.000000000000000878352095923549 - shared username, +3 password length for highly shared username

Thoughts? Ignorance misrepresented as thoughts? Unrelated comments?

[Edited on June 21, 2009 at 12:35 AM. Reason : .]

6/21/2009 12:27:36 AM

You just don't get it. I don't think anyone is trying to prove that what you want to do isn't mathematically possible.

Just that it's a FUCKING HORRIBLE IDEA.

Give it up already.

6/21/2009 12:32:47 AM

So you're arguing that usernames of the form "xoxolilhotty6969" are preferable to aliases you actually identify with? Yet another possibility I never considered.

You must also be forgetting that Facebook effectively did use a "shared username" system where you often used other attributes than login name to identify your contacts. This is the entire reason the discussion made it into this thread.

You people are intolerably dense.

6/21/2009 12:39:45 AM

You're confusing the naming system used to identify users to one another with the naming system used to identify users to the login system.

If you really can't see why having the same username for login purposes would be a horrible idea, then you really are beyond help.

6/21/2009 12:46:18 AM

Quote :

"You're confusing the naming system used to identify users to one another with the naming system used to identify users to the login system."

No, I'm not. I suggest you re-interpret my comment with this newfound understanding.

I'm not beyond help, you just don't have a fucking point of substance to make. Get it straight.

[Edited on June 21, 2009 at 12:51 AM. Reason : .]

6/21/2009 12:50:09 AM

You're making a fool out of yourself

6/21/2009 12:52:32 AM

At least if someone had the username of xoxolilhotty6969 they would be able to say "my name is xoxolilhotty6969 on facebook" and as completely retarded as you may think that is, people would be able to find them because they are the only one.

But if everyone else is allowed to pick the same username, ...

you know what? I feel like I'm arguing politics with an 8 year old. I said it before, and this is my last post in this thread. If you can't figure out one of the HUNDREDS of reasons why this is a bad idea, then you really are an absolute retard. I'm done trying. If this really was a troll, then GG all day long. But I do think you're really that stupid.

/out.

6/21/2009 12:55:32 AM

It's honestly difficult to determine whether you guys are trolling or just on the same page as RSXTypeS.

6/21/2009 12:56:15 AM

Shit, wrong thread.


[Edited on June 21, 2009 at 1:09 AM. Reason : /really out]

6/21/2009 1:07:57 AM

Quote :

"If there are 10,000 accounts named "Sarah", then the username "Sarah" should have a password length requirement 2 characters longer than an unshared username for the probability of brute force success to be roughly the same"

Yes, of course. Please hook me up with schematics to the time machine you're going to use to retroactively make the first Sarah's password stronger.

6/21/2009 6:58:30 AM

Even in the worst case with a static minimum password length of 8 characters, it's hardly a probability significant enough to worry about. See above.

There's further no need to increase the length requirement for the accounts created before a length requirement increase as they represent a minority of the shared accounts and would not reduce the password strength substantially. I would demostrate this mathematically, but then "nobody would be arguing" against that aspect again.

Finally, and let me note that I am stating this with the utmost disdain for your intellectual capacity and experience, you may have (but more than likely have not) heard of a (none-the-less fairly well known) feature in password-based authentication systems called an "invalidation". Go ahead and check out your control panel, you may notice the check box in the user properties panel beside "User must change password at next logon". IF the previous conditions somehow magically ceased to compute in this universe, the "TIME MACHINE" used to "RETROACTIVELY MAKE THE FIRST SARAH'S PASSWORD STRONGER" would be a boolean field in the database requiring the user to set a new password at the next logon. Fucking idiot. Go play with some plastic grocery bags and suffocate.

[Edited on June 21, 2009 at 8:06 AM. Reason : .]

6/21/2009 7:56:20 AM

12 character password requirements? Inexplicable failures on password strength checks? Constant password updates required?

Is this a social networking site or a fucking corporate intranet?

6/21/2009 8:30:38 AM

While Tiberius has proven that the likelihood a username would have a password conflict is mathematically improbable, it can still happen. And I don't think a site like Facebook would be dumb enough to take this risk. I think their system of using email addresses is pretty good; no two people can have the same email address.

6/21/2009 8:41:09 AM

Quote :

"I would describe this post as incoherent. I don't want to drop a dictionary on you, I assume you can pull it up and cross-reference."

I don't need to ask if you're an idiot because we all know the answer to that. What part of what I said confused you?

^and thats the tune i've been singing all along...but Tiberius thought he'd reinvent the wheel and sound smart doing it.

[Edited on June 22, 2009 at 1:13 AM. Reason : .]

6/22/2009 1:12:18 AM

Regardless of how you're logging in to whatever website you run, if you're not using OpenID, you're doing it wrong. With Facebook giving us unique aliases, it makes it so they can become an OpenID authentication provider, and not just a consumer... which is pretty cool. They joined the OpenID foundation a couple months ago, so this is probably something you'll see soon.

Conceivably, not only could you start putting "facebook.com/mycrappyband" on all of your crappy band's promo fliers... you can also authenticate yourself as facebook.com/mycrappyband on external websites, which gives a pretty sweet user experience.

Currently you can link your facebook account with an OpenID 2.0 provider (they don't support OpenID 1.1 for some reason).

6/22/2009 6:26:32 AM

Quote :

"you guys should blog about the traffic spike"

thx.

http://www.facebook.com/note.php?note_id=96390263919

Quote :

"Site Reliability Engineering (SRE) at Facebook is always under pressure to keep the site and all the moving pieces behind the scenes running while still delivering an excellent user experience. The recent launch of usernames to our 200 million active users on a single night at the exact same time was unique in its preparation and potential for trouble. Burst of memcache traffic at launch Our product teams had evaluated the various options for enabling people to register for their name and decided upon a single first come, first serve registration window for every user. Although this was the most fair, it was difficult operationally because predicting the number of users that would show up at that time to claim a name was impossible. The Memcached infrastructure that runs behind every page on the site was partitioned and expanded to cope with users checking the availability of names. It also supported our list of blocked names like Pizza, RonPaul and Beer. One terabyte of in-memory cache was dedicated exclusively for the username launch. Most pages on Facebook are comprised of multiple AJAX calls and other JavaScript/CSS resources, but the registration page for usernames was stripped down as much as possible to incur very little additional load on our web servers. Users were directed straight to this page for their registration, bypassing the more intensive parts of Facebook. We intentionally chose to launch the feature at a time of low site activity (Friday at 9PM Pacific) to help with the expected extra demand, and assembled people from many groups within Facebook to be in our "War Room" during the launch. The software engineers that wrote the code, network, system, and security engineers, SRE's, product managers, and anybody else that wanted to help out assembled for few hours eating Chinese food, drinking beer, and enabling usernames on Facebook. The launch of usernames was unprecedented because of its potential to affect the experience and stability of Facebook in a very real way. About a month prior to the big night we began planning for any possible contingency by performing background load testing with normal traffic. Additionally, we developed a comprehensive set of levers and knobs that would enable us to alter site functionality to cope with the extra demand. * "Dark Launching": During the two weeks prior to launch we began what we call a "dark launch" of all the functionality on the backend. Essentially a subset of user queries are routed to help us test, by making "silent" queries to the code that, on launch night, will have to absorb the traffic. This exposes pain points and areas of our infrastructure that needs attention prior to the actual launch. Increasing the demand on one subsystem may generate more logs than anticipated and overwhelm analysis processes, or unexpected network bottlenecks may appear. "Dark launching" allows us to stress test parts of Facebook before it would be apparent, while still simulating the full effect of launching the code to real users. * Levers and the "Nuclear Option": We couldn't be sure of the exact level of traffic the launch would generate so we put together contingency plans to decrease the load on various parts of the site. This gave us overhead in core functionality at the expense of less essential services. Facebook comprises hundreds of interlocking systems, although to users it's presented as a simple web page. Throttling back the behavior of certain facets allows us to lighten the demand on our infrastructure without compromising major site functionality. The time required to make most of these changes is usually less than a minute. Some of the levers at our disposal were: o Altering Facebook Chat to be less feature-rich by turning off typing notifications, new item notifications, and slowing down how often clients refresh their buddy lists. o Decreasing the default number of stories on the Home and Profile pages. o Switching off entire parts of the site like the bottom chat bar, the highlights to the right of news feed, "People You May Know", and commenting on/liking of stories. o "Nuclear Options": In the event that Facebook became overwhelmed with traffic and suffered performance problems as a result we also prepared for what we called 'Nuclear Options' such as cutting off nearly all the functionality on the Profile page, turning off Facebook Chat, and completely disabling the Home page. Any of these options were an absolute last resort to keep the site functional as they would have resulted in a severely degraded user experience. All this preparation paid off on launch night. In the first three minutes over 200,000 people registered names, with over 1 million allocated in the first hour, and none of our "nuclear option" levers had to be used at any point. Through the entire launch we had no issues handling the additional load. Launch Team Our next big event is coming up and we're already stressing the infrastructure to ensure a smooth launch. If the challenges of supporting the infrastructure behind one of the largest sites on the Internet makes you excited, check out our open SRE, Engineering, and other Operations positions at facebook.com/careers."

[Edited on July 2, 2009 at 4:04 PM. Reason : ONE TERABYTE MEMCACHE!!! ]

7/2/2009 4:00:56 PM

Quote :

"ONE TERABYTE MEMCACHE!"

7/2/2009 6:35:27 PM

cool another post. gg fb

http://www.facebook.com/note.php?note_id=114979233919

Quote :

"We recently hit a milestone of 50MM usernames a few weeks ago — in just over a month since we launched usernames on June 12. Ever since we launched usernames, we’ve had a lot of people express interest in understanding how we designed the system and prepared for this big event. In a recent post, my colleague Tom Cook wrote about the site reliability and infrastructure work that we did to ensure a smooth launch. As an extension to that post, I’ll discuss some specific application and system design issues here. Launching usernames to allow over 200 million (at the time — we’re now over 250 million) people to get a username at the same time presented some really interesting performance and site reliability challenges. The two main parts of the system that needed to scale were (1) the availability checker and (2) the username assigner. Since we were pre-generating suggestions for users, we needed to check availability of all the suggested names, which placed extra load on the availability checker. Optimizing read and write performance It became clear to us that the database tier would not be able to handle the huge initial load for availability checks. Even caching the results of availability check calls would not have helped much since the hit rates would be low. To solve these problems, we created a separate memcache tier to store all assigned usernames. Checking if a username is available is just a quick lookup in this memcache tier. If the lookup returns no result, we assume the name is available. This allowed us to completely eliminate any dependency on the database tier for availability checks. To distribute the availability check load across several memcache nodes, we replicated the cache across several machines in each of our data centers. We allocated about 1TB of memory for the entire username memcache tier. This design meant that we were using memcache as the authoritative data source for checking availability. This was a non-trivial decision to make, and we had to design special fault tolerance mechanisms (described in the next section) to make this reliable. When a username is assigned, the data is written to the database for a reliable, persistent record of the transaction. The username is also added to all the nodes in the replicated memcache tier. Writing the data to multiple memcache nodes implied a slight drop in write performance, but since we expected the read load to be much higher than the write load, this was a good trade-off to make. For detecting conflicts when multiple users try to grab a name at the same time, we used an optimistic concurrency control mechanism. This improved write performance by eliminating the need to hold locks. We also briefly considered using Bloom Filters, but quickly came to the conclusion that it wasn’t the best solution for our problem because (1) space efficiency was not a primary concern since we could fit many hundreds of millions of usernames in memory in a single machine (2) Bloom Filters can cause false positives (incorrect hits) and (3) removing items from them is not simple. Fault tolerance One of the issues with using memcache as the system of record for availability checks is that memcache nodes can go down. While the redundant memcache boxes provided some fault tolerance, we wanted to design a system that would allow us to bring back failed nodes easily. To enable that, we wrote a script that can populate a username memcache node from log files that contain all the assigned usernames. The log files are written to Scribe as part of assigning a username. We also used the Scribe logs to build a real-time data collector that provided a real-time report of the number of assigned usernames with a latency of just a few seconds. Another issue with memcache is that writes to memcache are not transactional and hence are not guaranteed to succeed 100% of the time. This means that we might occasionally say that a username is available when it really isn’t. Note that if the user tries to grab such a name, it will fail since the database is the ultimate source of truth. However, since this is not an ideal user experience, we made our system robust through a couple of mechanisms. First, to reduce the probability of incorrect misses, we always check a second memcache node for any miss in the first node. Second, any time that the process of assigning a username fails in the database due to an already assigned name, we will re-populate all memcache nodes with that name so that we can prevent future users from experiencing the same problem. Load Testing Since it was difficult to get accurate estimates on the number of users that would login at launch time to get a username, we tested our systems under fairly high load – in fact, we stress tested our system with more than 10x the load we actually saw at launch time. The load testing helped us identify several problems in our infrastructure including but not limited to (1) improperly configured networks (2) bottlenecks in our database id generation mechanism (to generated primary keys for certain objects) (3) capacity bottlenecks for write traffic originating from our east coast data center. Contingency Planning Since we didn’t have accurate estimates on the traffic that the launch would generate, we put together contingency plans to decrease the load on various parts of the site to give us extra capacity in core services at the expense of less essential services. Also affectionately referred to as “nuclear options”, some of these levers included disabling chat notifications, showing fewer stories in the home page and profile page and completely turning off other parts of the site such as the People You May Know service, the entire chat bar, etc. Our careful design and planning paid off on launch night and later. In the first three minutes over 200,000 people registered names, with over 1 million allocated in the first hour, and over 50MM in just over a month. Through the entire launch we had no issues handling the additional load and none of our "nuclear options" had to be used at any point. However, two of our memcache nodes went down a few weeks after launch, but our scribe log replay scripts helped us to bring them back up again. Srinivas Narayanan, an engineer at Facebook, is excited about being able to visit most of his friends’ profiles through their usernames"

8/18/2009 1:38:21 AM

screw facebook. they took away my username

8/18/2009 7:21:33 AM

Does anyone really give a crap about facebook usernames? I mean yeah most of us have one now, but I don't ever pay attention to the damn things. I completely forgot about them until I saw this post again.

8/18/2009 9:29:36 PM

I would give a ball hair or two to work on that network.

8/18/2009 9:33:59 PM

I feel pretty damn cool having facebook.com/philihp

8/19/2009 12:51:02 AM

Quote :

"I would give a ball hair or two to work on that network."

put your resume where your mouth is

8/19/2009 1:35:58 AM

Quote :

"I feel pretty damnIt's kinda cool having facebook.com/philihpjtmartin"

8/19/2009 2:22:21 AM

i'm pretty happy with facebook.com/joshzilla

8/19/2009 2:27:54 AM

^^^

hehe, if it weren't for my geographical limitations, i'd be all over that.

8/19/2009 9:22:23 AM

Quote :

"Srinivas Narayanan, an engineer at Facebook, is excited about being able to visit most of his friends’ profiles through their usernames"

this guy was especially tired of people having to sift through the pages upon pages of people with his exact same name, right?

actually, sarcasm aside, he was probably tired of people misspelling both parts of his name and not being able to find him.

8/19/2009 12:26:41 PM