A look inside Facebook's source code
sintheticlabs.com
sintheticlabs.com
It's also interesting that Facebook developers are using Pastebin for things such as this. I would assume that they'd have an internal wiki, or gist-like app.
It's also noteworthy to see how they set up their accounts: first initial, full lastname—same standard as many other companies. But seeing it laid out can help in the guessing of other names (or common name occurances, as you don't even need a full first name).
While some leaks may not even be effective outside Facebook's internal network (things such as database credentials, network shares… hopefully), having actual code that may be in production does pose a risk. The possiblity to see where, for instance, data isn't fully sanitized, or where information being fetched might not require proper authentication[1] is more worrying. Facebook is known for promoting "move fast and break things". Hopefully they have good QA and SDET teams to catch these things.
[2] One code snippet features the following: > // TODO: add privacy checks!
There is no preset format for unixnames. Most people use their names but I've seen many pseudonyms. One intern famously broke some internal tools by requesting her initials, which were "www".
More like exposed implementation and/or design flaws in internal tools.
>Okay, so it's not the most secure password. But Facebook's database servers are heavily firewalled. Though if you do manage to break in to Facebook's servers, there's the password.
What is the point on even having a database password? The application itself needs access to the database, so the application needs to know the password.
That means that an attacker who gains access to the application can easily just look at the file where the password is stored and then use that to access the database.
Even if you'd go great lengths at keeping asking for the password at server start and only keeping it in memory - once an attacker is on the application server, the password is in memory and can be snooped.
So the question is: Why even use a password for the web application? In my case, I'll just let the application servers connect to the database without password.
Auditing (per tool)?
Not all attackers come "through the front door"
Fuck-ups happen, and an insecure password does a good job of preventing any activity that doesn't explicitly include the password.
Like, suppose you have some dev tool that does things to a database. If your local dev environment does not have a password on the db, and the application environment does, odds are your tool is going to work locally but not in the application environment.
Basically, it can be a form of "type 'password1' if you are sure you want to do things to prod".
This procedure then can apply additional predicates to the query.
When this procedure belongs to the schema that is not directly accessible to the user, then it would be possible to create a filter such that only logged in user can see the records and only her records.
"Oh, our staging code references the prod DB password. Wups!"
Passwords can also be changed and rotated with some frequency, though that's more often observed in the breech.
Preferably not the data breech.
https://github.com/search?p=96&q=gmail+password&ref=searchre...
even if they have 2-step auth setup, people choose "complete the email address" as a form of authentication which you can most likely get from their github profile.
the moral of the story here is - if you do not want someone to find it - do not publish it online
edit: I know that it is not ethical and I am only slightly tempted to do it but is it actually illegal to use open source code in that way?
You can compare it to opening someone's home because he left his key in a public place unbeknownst to him.
You generally couldn't make the argument that 'he may have wanted people to have the key, that's why he left it in a public/open source place'. Firstly, one can't assume that, so we must hear it explicitly before it's true. And secondly, if universal open-source access was provided, there wouldn't be a key to find as there wouldn't be a lock in the first place to allow specific access. The whole point of a password or key means you do not want fully open access to all, meaning any password or key in an open-source project is likely unintentional, a mistake, and thus you'd be entering without permission which is illegal in most jurisdictions.
Reminds me of a story where a hosted bitcoin wallet was open-sourced right after they shut down. It was completely uploaded to github, including credentials that indirectly allowed access to an exchange where they stored a lot of their funds. It was a stupid company ran by careless people in the first place (they got hacked 2-3 times before open-sourcing an API key that was the same as a LastPass password that held their exchange password). About $350k was stolen. ($14 million by today's standards.)
https://github.com/search?p=4&q=extension%3A.key+BEGIN+RSA+P...
https://github.com/Dao007forever/Linux-settings/blob/master/...
https://github.com/Dao007forever/Linux-settings/blob/master/...
https://github.com/Dao007forever/Linux-settings/blob/master/...
> the moral of the story here is - if you do not want someone to find it - do not publish it online
I doubt it's intentional. I will note that on Windows, if you're using ActiveDirectory, it's much more difficult to make this kind of mistake.
Mostly as I gave up ever trying to do anything with Bitcoin because I simply can't get my head around any of the practicalities, lol, so it definitely wasn't anything of mine! ;-)
It too contains the password "e5p0nd4". This user didn't do any hacking or googling but got this error browsing facebook. He says "Suddenly I got this error message in Facebook" (so apparently inside the production environment, wtf?).
[1] https://forums.digitalpoint.com/threads/facebook-error-messa...
[2] http://www.zyngaplayerforums.com/archive/index.php/t-545034-... - Another one from 2010!
EDIT - there is - i had no clue: http://pastebin.com/api#1