So, what would be the fallout of a MeFi security breach? February 18, 2015 10:39 PM Subscribe
Are my embarrassing anonymous questions permanently associated with my regular account? I think I used a credit card to pay for my registration; is my credit card information (and thus real name and address) still on record?
Imagine the scenario where the site is completely compromised and a dump of the database makes its way out as a public torrent. How vulnerable do I become?
Imagine the scenario where the site is completely compromised and a dump of the database makes its way out as a public torrent. How vulnerable do I become?
Anonymous questions have no link to user IDs in the database, so you would be fine. Credit cards are not given to us at all, that's all at PayPal. We never get your address. We do have a name associated with a PayPal which we use for identity purposes.
About the only private things I'd say would be MeFi Mails and your IPs on posts. Basically everything you do and post at MeFi is public, so the amount of hidden info that would be in the db is pretty minimal.
posted by mathowie (staff) at 10:54 PM on February 18, 2015 [4 favorites]
About the only private things I'd say would be MeFi Mails and your IPs on posts. Basically everything you do and post at MeFi is public, so the amount of hidden info that would be in the db is pretty minimal.
posted by mathowie (staff) at 10:54 PM on February 18, 2015 [4 favorites]
In a previous MeTa, cortex gave a bit more info on how the Anonymous function works as far as this stuff. Just the MeFi db alone doesn't contain enough info to out anon question askers, but the db plus the mods' email does.
Sock puppet identities would be another thing that would affect your privacy. In many (most?) cases, mods can see that two accounts belong to the same person.
posted by LobsterMitten (staff) at 11:29 PM on February 18, 2015 [1 favorite]
Sock puppet identities would be another thing that would affect your privacy. In many (most?) cases, mods can see that two accounts belong to the same person.
posted by LobsterMitten (staff) at 11:29 PM on February 18, 2015 [1 favorite]
Thanks, all, for the info. This is reassuring.
"We do have a name associated with a PayPal which we use for identity purposes." Is the name kept after registration is complete? (Does it need to be?)
posted by mf_ss at 12:48 AM on February 19, 2015
"We do have a name associated with a PayPal which we use for identity purposes." Is the name kept after registration is complete? (Does it need to be?)
posted by mf_ss at 12:48 AM on February 19, 2015
Yeah, it would be difficult but not impossible for them to figure out it was you who asked about the thing on your thing.
posted by Justinian at 1:31 AM on February 19, 2015 [3 favorites]
posted by Justinian at 1:31 AM on February 19, 2015 [3 favorites]
In theory, a clever linguistics analysis could link an anonymous poster with their MeFI account (or vice versa), but you'd have to have some pretty idiosyncratic writing habits for it to identify you with any degree of confidence.
posted by kisch mokusch at 1:39 AM on February 19, 2015 [1 favorite]
posted by kisch mokusch at 1:39 AM on February 19, 2015 [1 favorite]
Yes, the PayPal name is kept. It's sometimes useful for weeding out spammers and keeping track of identity-related shenanigans, e.g. people registering a variety of sock puppet accounts under different "real" names, etc. I'd imagine the (PayPal) email address would probably be enough to indicate a "unique PayPal user" but having the name is useful to us simply because it's likely to refer to a person (even though personal names are not necessarily unique). So it happens regularly that folks use a different email address for PayPal than they do for signing up to MeFi; having the name means we can sometimes link the two data points while checking out spammy-looking fresh accounts and the like.
posted by goodnewsfortheinsane (staff) at 1:58 AM on February 19, 2015 [1 favorite]
posted by goodnewsfortheinsane (staff) at 1:58 AM on February 19, 2015 [1 favorite]
but you'd have to have some pretty idiosyncratic writing habits for it to identify you with any degree of confidence.
There are some strongly idiosyncratic writers here, but I've never seen an anonymous question that was identifiable at a glance that way. (I have seen quite a few people post anonymous questions and then almost immediately out themselves in the answer section, which seems like a wasted effort by all concerned.)
posted by Dip Flash at 4:24 AM on February 19, 2015 [3 favorites]
There are some strongly idiosyncratic writers here, but I've never seen an anonymous question that was identifiable at a glance that way. (I have seen quite a few people post anonymous questions and then almost immediately out themselves in the answer section, which seems like a wasted effort by all concerned.)
posted by Dip Flash at 4:24 AM on February 19, 2015 [3 favorites]
I too would like to know what the password storage system is. What algorithm, how many rounds, is a salt used, etc.
posted by alby at 6:24 AM on February 19, 2015
posted by alby at 6:24 AM on February 19, 2015
mf_ss: "Imagine the scenario where the site is completely compromised and a dump of the database makes its way out as a public torrent."
Flush the bombers, get the subs in launch mode. We are at DEFCON 1.
posted by Chrysostom at 6:44 AM on February 19, 2015 [3 favorites]
Flush the bombers, get the subs in launch mode. We are at DEFCON 1.
posted by Chrysostom at 6:44 AM on February 19, 2015 [3 favorites]
Yes, the password is stored as a one-way, salted, SHA-256 hash. The salt is unique to each user and is stored when the password is created or changed. We moved to this system in 2007, around the time Jeff Atwood made this post. It's a great introduction to why we store passwords this way.
posted by pb (staff) at 6:59 AM on February 19, 2015 [10 favorites]
posted by pb (staff) at 6:59 AM on February 19, 2015 [10 favorites]
My understanding has always been that MeFi has shied away from trying to provide strong privacy for anonymous Asks, somewhat intentionally. It's much easier (and more realistic) to just say, "Your anonymous questions will virtually always remain anonymous, but don't bet your life on it," and then have a system that's more than good enough for day-to-day privacy purposes but which doesn't even really try to account for more extreme situations like the one hypothesized in this MeTa. As it turns out, it would be non-trivial to link all anonymous Asks to their Askers even in the event of a major database breach, but that's more a matter of happy accident than intentional design.
It's seemed to me that it's mostly about setting expectations. If MeFi Inc. were to say, "We guarantee that under no circumstances will your anonymous questions ever be traced back to you," then they would have a much harder task ahead of them and would be putting themselves in the way of a lot of angry, disappointed users (and possibly some lawsuits) in the event that their security measures ever failed. As it is, they can just shrug and say, "Well, we told you not to bet your life on it. If you needed to ask a question where having it traced back to you could cost you your job, you shouldn't have done it here."
MetaFilter wisely avoids trying to be all things to all people. This is one of those cases where it seems like the mod team is avoiding a goal that could be unrealistic and rather fraught, and I can totally see why they've chosen to go that route. Similarly, I believe, MeFi has a stated position that it will not necessarily even try to resist any law-enforcement inquiries or demands for user information—something that is worth bearing in mind, if you find yourself relying heavily on a shield of pseudonymity to prevent your comment history from getting you into trouble. They've always been pretty up front about this stuff, so I personally have always been pretty fine with it.
posted by Anticipation Of A New Lover's Arrival, The at 7:06 AM on February 19, 2015 [3 favorites]
It's seemed to me that it's mostly about setting expectations. If MeFi Inc. were to say, "We guarantee that under no circumstances will your anonymous questions ever be traced back to you," then they would have a much harder task ahead of them and would be putting themselves in the way of a lot of angry, disappointed users (and possibly some lawsuits) in the event that their security measures ever failed. As it is, they can just shrug and say, "Well, we told you not to bet your life on it. If you needed to ask a question where having it traced back to you could cost you your job, you shouldn't have done it here."
MetaFilter wisely avoids trying to be all things to all people. This is one of those cases where it seems like the mod team is avoiding a goal that could be unrealistic and rather fraught, and I can totally see why they've chosen to go that route. Similarly, I believe, MeFi has a stated position that it will not necessarily even try to resist any law-enforcement inquiries or demands for user information—something that is worth bearing in mind, if you find yourself relying heavily on a shield of pseudonymity to prevent your comment history from getting you into trouble. They've always been pretty up front about this stuff, so I personally have always been pretty fine with it.
posted by Anticipation Of A New Lover's Arrival, The at 7:06 AM on February 19, 2015 [3 favorites]
one-way, salted, SHA-256 hash
That's also my standard greasy spoon breakfast order and it's absolutely delicious.
posted by kate blank at 7:53 AM on February 19, 2015 [35 favorites]
That's also my standard greasy spoon breakfast order and it's absolutely delicious.
posted by kate blank at 7:53 AM on February 19, 2015 [35 favorites]
one-way, salted, SHA-256 hash
Ahahaha, that Jeff Atwood post. Christ. Some blogger telling you how you should do cryptography, followed by a disclaimer that the author is not a cryptographer, followed by a critique from an actual cryptographer telling you to just use bcrypt.
p.s. metafilter should just use bcrypt
posted by ryanrs at 8:08 AM on February 19, 2015 [9 favorites]
Ahahaha, that Jeff Atwood post. Christ. Some blogger telling you how you should do cryptography, followed by a disclaimer that the author is not a cryptographer, followed by a critique from an actual cryptographer telling you to just use bcrypt.
p.s. metafilter should just use bcrypt
posted by ryanrs at 8:08 AM on February 19, 2015 [9 favorites]
There are some strongly idiosyncratic writers here, but I've never seen an anonymous question that was identifiable at a glance that way.
I've noticed a few (I'm talking like 3 or 4 tops) over the years, and I'm probably what you would classify as a Heavy User of askme.
There was one person once who consistently closed their parentheses funny, like "(here is a thing .)" and another who had a weird typo of a common word that I don't remember.
More often people out themselves by having particular pet topics and putting a lot of personal detail into non-anonymous questions, and then asking roughly the same question anonymously once they start getting "you ask this question every week, what are you hoping to achieve" in the answers.
All of them are fiamo moments.
posted by phunniemee at 8:38 AM on February 19, 2015 [1 favorite]
I've noticed a few (I'm talking like 3 or 4 tops) over the years, and I'm probably what you would classify as a Heavy User of askme.
There was one person once who consistently closed their parentheses funny, like "(here is a thing .)" and another who had a weird typo of a common word that I don't remember.
More often people out themselves by having particular pet topics and putting a lot of personal detail into non-anonymous questions, and then asking roughly the same question anonymously once they start getting "you ask this question every week, what are you hoping to achieve" in the answers.
All of them are fiamo moments.
posted by phunniemee at 8:38 AM on February 19, 2015 [1 favorite]
So it happens regularly that folks use a different email address for PayPal than they do for signing up to MeFi;
So the hypothetical hacker would get both of these addresses, right? Mine are the same, and it's on my profile page, but that's not always the case.
posted by ODiV at 8:44 AM on February 19, 2015
So the hypothetical hacker would get both of these addresses, right? Mine are the same, and it's on my profile page, but that's not always the case.
posted by ODiV at 8:44 AM on February 19, 2015
Ahahaha, that Jeff Atwood post. Christ.
Why the snide attitude? At the time we were storing passwords in plain text. His post prompted us to change things, and the method he describes for storing passwords is industry standard for sites like MetaFilter and his Stack Overflow. If there's a problem with our choice of hashing algorithm we can review that, but it would help to get some information about it. We aren't cryptographers either.
Most of the information at MetaFilter is public. I'm not sure there's much incentive for people use server farms to break a hash here.
posted by pb (staff) at 9:32 AM on February 19, 2015 [6 favorites]
Why the snide attitude? At the time we were storing passwords in plain text. His post prompted us to change things, and the method he describes for storing passwords is industry standard for sites like MetaFilter and his Stack Overflow. If there's a problem with our choice of hashing algorithm we can review that, but it would help to get some information about it. We aren't cryptographers either.
Most of the information at MetaFilter is public. I'm not sure there's much incentive for people use server farms to break a hash here.
posted by pb (staff) at 9:32 AM on February 19, 2015 [6 favorites]
Yes, the notional hacker would be able see both your paypal-associated email address and the address listed in your email field in your preferences. If the fact that you own a given email address is a matter of catastrophic security risk, my recommendation is to not list that email address in your preferences; if the email address associated with your paypal account is a similarly catastrophic risk, that's a more idiosyncratic situation but you're welcome to drop us a line at the contact form about it.
With all things privacy-minded, our goal is to try hard to give users reasonable day-to-day privacy/pseudonymity on Metafilter to the degree that they want it; on our end that's by trying to keep the server reasonably secure and by making a point, as moderators, to respect privacy issues by not unilaterally disclosing private information about users to the public. We won't tell random people who posted an anonymous question; we won't distribute contact information to third parties, or intentionally out someone's real life identity.
That doesn't mean you have total privacy from the mods: there are some things we need to be able to do our jobs well even if other users or the public have no access to that info. Keeping spammers and ban-dodgers at bay involves a fair amount of digging and correlation; following up on things like suicide-related questions and other such difficult edge-cases can likewise. Even helping a user get back into their account after a long break requires knowing a little bit more about who is who than the public needs to. So we operate at a level of compromise where we try to provide reasonable privacy at a public-facing level but maintain more than a literally-no-data-on-anybody level of info so we can do our jobs.
Which is why that also doesn't mean you have total privacy in the face of some sort of catastrophic intrusion, whether by hackers or by governmental entities. Things that are profoundly unlikely to happen are still things that can, in theory, happen, and we are not a hardened island crypto nation; if you need paranoia-grade privacy for some sort of personal information, Metafilter is not an appropriate place to store it.
If you are worried in a general way about the idea of hackers or the NSA or whomever getting access to things you put on Metafilter, it makes sense to stop and consider what you post on the site and whether you need to modify your choices in the future to feel more comfortable. If you have questions about that, you can totally ask us.
If you are worried in a very specific, "I know for a fact that this sensitive item is in the server and that's a potential catastrophic risk for me" way about some individual thing, you can drop us a line about that as well and we can talk about it.
My opinion is that the degree of privacy we provide is sufficient for just about everything that should actually ever be happening on Metafilter in the first place, but personal privacy is personal privacy and basically everyone needs to do their own risk assessment and risk management periodically because nobody else can really do it for you.
posted by cortex (staff) at 9:36 AM on February 19, 2015 [2 favorites]
With all things privacy-minded, our goal is to try hard to give users reasonable day-to-day privacy/pseudonymity on Metafilter to the degree that they want it; on our end that's by trying to keep the server reasonably secure and by making a point, as moderators, to respect privacy issues by not unilaterally disclosing private information about users to the public. We won't tell random people who posted an anonymous question; we won't distribute contact information to third parties, or intentionally out someone's real life identity.
That doesn't mean you have total privacy from the mods: there are some things we need to be able to do our jobs well even if other users or the public have no access to that info. Keeping spammers and ban-dodgers at bay involves a fair amount of digging and correlation; following up on things like suicide-related questions and other such difficult edge-cases can likewise. Even helping a user get back into their account after a long break requires knowing a little bit more about who is who than the public needs to. So we operate at a level of compromise where we try to provide reasonable privacy at a public-facing level but maintain more than a literally-no-data-on-anybody level of info so we can do our jobs.
Which is why that also doesn't mean you have total privacy in the face of some sort of catastrophic intrusion, whether by hackers or by governmental entities. Things that are profoundly unlikely to happen are still things that can, in theory, happen, and we are not a hardened island crypto nation; if you need paranoia-grade privacy for some sort of personal information, Metafilter is not an appropriate place to store it.
If you are worried in a general way about the idea of hackers or the NSA or whomever getting access to things you put on Metafilter, it makes sense to stop and consider what you post on the site and whether you need to modify your choices in the future to feel more comfortable. If you have questions about that, you can totally ask us.
If you are worried in a very specific, "I know for a fact that this sensitive item is in the server and that's a potential catastrophic risk for me" way about some individual thing, you can drop us a line about that as well and we can talk about it.
My opinion is that the degree of privacy we provide is sufficient for just about everything that should actually ever be happening on Metafilter in the first place, but personal privacy is personal privacy and basically everyone needs to do their own risk assessment and risk management periodically because nobody else can really do it for you.
posted by cortex (staff) at 9:36 AM on February 19, 2015 [2 favorites]
There are some strongly idiosyncratic writers here, but I've never seen an anonymous question that was identifiable at a glance that way.
I once posted an anonymous question and a friend of mine, also a Mefite, immediate emailed me with an answer. She didn't even ask if it was me, she just knew. I didn't think it was all that obvious that it was me.
I have seen quite a few people post anonymous questions and then almost immediately out themselves in the answer section, which seems like a wasted effort by all concerned.
I think sometimes people post anonymous questions partially to not have it show up in their history but otherwise don't really care if people know who posted it. I've outed myself after the fact once or twice, though in different threads.
posted by bondcliff at 10:25 AM on February 19, 2015 [3 favorites]
I once posted an anonymous question and a friend of mine, also a Mefite, immediate emailed me with an answer. She didn't even ask if it was me, she just knew. I didn't think it was all that obvious that it was me.
I have seen quite a few people post anonymous questions and then almost immediately out themselves in the answer section, which seems like a wasted effort by all concerned.
I think sometimes people post anonymous questions partially to not have it show up in their history but otherwise don't really care if people know who posted it. I've outed myself after the fact once or twice, though in different threads.
posted by bondcliff at 10:25 AM on February 19, 2015 [3 favorites]
ereptilebutts was a kinda obvious sock, TBH.
posted by maryr at 11:41 AM on February 19, 2015 [5 favorites]
posted by maryr at 11:41 AM on February 19, 2015 [5 favorites]
pb:
You don't need a server farm to break a salted SHA-256 hash. Consider the salt (nearly) useless for SHA-256. Hardware has gotten so fast and cheap for MD5/SHA/etc. that it's rarely worth using rainbow table attacks anyway. Consider that a cheap modern Intel desktop processor has built-in instructions for doing SHA-1 and SHA-256 hashes: it takes (just over) a whole 128 instructions to compute an entire SHA-256 hash! Just over $1k of desktop computer (a common rig with a pair of $200ea video cards, much like a lot of gamers own) gets you in the neighborhood of 2 Ghash/sec. A dedicated hashing rig, now quite common since bitcoin/etc. are a Thing, will do much more. So let's do some quick back-of-the-envelope math, all assuming that cheap desktop machine:
A big broad-but-shallow dictionary attack (100M entries) against a single salted SHA-256 hashed user password will take ~50 ms. That's for all known entries in the wordlist. So attacking 200k user entries will take about 10k seconds. That's under 3 hours to do a shallow attack on the entire user db. Basic common-variant attacks will start at about 10x that work. Thirty hours. That's totally worthwhile for nearly any attacker to attempt because some people will use the same email/username and password on other (valuable) sites. And you don't have to "run to the end" and do a 100% exhaustive analysis: you run it, it starts with the most trivial passwords/variants, and matching hashes (correct passwords) fall out of the bottom for the low-complexity passwords; you just abort the attack when you've got enough matches to make your payoff. So maybe you only crack 10 or 20% of the database -- big deal, except to those 10% or 20% of your users.
And, again, this is assuming cheap desktop hardware. A few-kilobuck GPU hasher is a relative nightmare.
Now we might argue that people using passwords that a password cracker will quickly find (dictionary words, pairs of such, appended numbers, trivial capitalization modifications, etc.) aren't really very secure anyway, but consider the same attack using something like bcrypt/PBKDF2/etc.: instead of 2 Ghash/sec you can trivially adjust the difficulty parameter of the algorithm to yield, say, 100 ms runtime on current hardware. That's 10 hash/sec. Eight orders of magnitude difference. Your server can't handle 100 ms delay on the password check? Turn it down to 10ms. Or 1ms. It's still millions of times slower for an attacker.
Give the broad availability of bcrypt/PBKDF2/etc. libraries, it's nearly criminally-negligent to be using a fast hash for password comparisons these days.
posted by introp at 12:25 PM on February 19, 2015 [12 favorites]
Why the snide attitude? At the time we were storing passwords in plain text. His post prompted us to change things, and the method he describes for storing passwords is industry standard for sites like MetaFilter and his Stack Overflow. If there's a problem with our choice of hashing algorithm we can review that, but it would help to get some information about it. We aren't cryptographers either.That wasn't me with the original comment, but here's some data for thought:
Most of the information at MetaFilter is public. I'm not sure there's much incentive for people use server farms to break a hash here.
You don't need a server farm to break a salted SHA-256 hash. Consider the salt (nearly) useless for SHA-256. Hardware has gotten so fast and cheap for MD5/SHA/etc. that it's rarely worth using rainbow table attacks anyway. Consider that a cheap modern Intel desktop processor has built-in instructions for doing SHA-1 and SHA-256 hashes: it takes (just over) a whole 128 instructions to compute an entire SHA-256 hash! Just over $1k of desktop computer (a common rig with a pair of $200ea video cards, much like a lot of gamers own) gets you in the neighborhood of 2 Ghash/sec. A dedicated hashing rig, now quite common since bitcoin/etc. are a Thing, will do much more. So let's do some quick back-of-the-envelope math, all assuming that cheap desktop machine:
A big broad-but-shallow dictionary attack (100M entries) against a single salted SHA-256 hashed user password will take ~50 ms. That's for all known entries in the wordlist. So attacking 200k user entries will take about 10k seconds. That's under 3 hours to do a shallow attack on the entire user db. Basic common-variant attacks will start at about 10x that work. Thirty hours. That's totally worthwhile for nearly any attacker to attempt because some people will use the same email/username and password on other (valuable) sites. And you don't have to "run to the end" and do a 100% exhaustive analysis: you run it, it starts with the most trivial passwords/variants, and matching hashes (correct passwords) fall out of the bottom for the low-complexity passwords; you just abort the attack when you've got enough matches to make your payoff. So maybe you only crack 10 or 20% of the database -- big deal, except to those 10% or 20% of your users.
And, again, this is assuming cheap desktop hardware. A few-kilobuck GPU hasher is a relative nightmare.
Now we might argue that people using passwords that a password cracker will quickly find (dictionary words, pairs of such, appended numbers, trivial capitalization modifications, etc.) aren't really very secure anyway, but consider the same attack using something like bcrypt/PBKDF2/etc.: instead of 2 Ghash/sec you can trivially adjust the difficulty parameter of the algorithm to yield, say, 100 ms runtime on current hardware. That's 10 hash/sec. Eight orders of magnitude difference. Your server can't handle 100 ms delay on the password check? Turn it down to 10ms. Or 1ms. It's still millions of times slower for an attacker.
Give the broad availability of bcrypt/PBKDF2/etc. libraries, it's nearly criminally-negligent to be using a fast hash for password comparisons these days.
posted by introp at 12:25 PM on February 19, 2015 [12 favorites]
But would a hacker be able to find out our edit window "Units of Change" ratio? That's what I want to know.
posted by anotherpanacea at 12:32 PM on February 19, 2015 [2 favorites]
posted by anotherpanacea at 12:32 PM on February 19, 2015 [2 favorites]
it's nearly criminally-negligent to be using a fast hash for password comparisons these days.
Isn't this also presuming that there are no other rate-limiting options that are piled on top of this? Or is this assuming there's some way to get at the password tables themselves somehow as in the original question?
I mean I get what you are saying, people's bad password hygiene generally makes places like this attractive for people to attack the passwords so they can get at some user/pass combos that get reused someplace that has data you WANT. At the same time how much is it your responsibility to shore up your password system just because people might be protecting data elsewhere with the same passwords? What's the standard nowadays?
As people have said above, the most you'd get here is people's paypal addresses and maybe IP addresses (which could maybe be collated against anon questions, but it would be time-consuming work) and flags and flagged information. And admin notes, let's not forget them.
posted by jessamyn (retired) at 12:42 PM on February 19, 2015
Isn't this also presuming that there are no other rate-limiting options that are piled on top of this? Or is this assuming there's some way to get at the password tables themselves somehow as in the original question?
I mean I get what you are saying, people's bad password hygiene generally makes places like this attractive for people to attack the passwords so they can get at some user/pass combos that get reused someplace that has data you WANT. At the same time how much is it your responsibility to shore up your password system just because people might be protecting data elsewhere with the same passwords? What's the standard nowadays?
As people have said above, the most you'd get here is people's paypal addresses and maybe IP addresses (which could maybe be collated against anon questions, but it would be time-consuming work) and flags and flagged information. And admin notes, let's not forget them.
posted by jessamyn (retired) at 12:42 PM on February 19, 2015
Another security pro dropping in to say use bcrypt or PBKDF2. The others have posted the why already, so this is just my +1.
I'd be especially tickled if you guys supported two factor with Google or Facebook.
posted by bfranklin at 12:55 PM on February 19, 2015 [4 favorites]
I'd be especially tickled if you guys supported two factor with Google or Facebook.
posted by bfranklin at 12:55 PM on February 19, 2015 [4 favorites]
Password database attacks are generally offline. The typical scenario is that an attacker finds some way to gain access to the user database, exfiltrates it, and attacks it at their leisure. This basically describes 99% of password database attacks. (If this weren't so, there would be almost no harm in storing the passwords in plaintext: if the only access the attacker has is through your rate-limiting system, you can guard against the exposure of passwords with that system itself.)
The standard nowadays is bcrypt. It's been around a long time and is well-analyzed. It's probably marginally more secure than PBKDF2 (more resistant to attacks like GPU parallelization), though NIST deems PBKDF2 sufficient if the difficulty parameter is set right. scrypt may be even more secure (more resistant to small-memory FPGA/ASIC attacks that a wealthy or state actor might use) but it's also new enough that it's still viewed with some skepticism.
I mean, other than the migration of old password fields to new ones, the changes in using one hasher versus another is going to be something like changing:
import hashlib
if hashlib.sha256(userSalt . submittedPassword).digest() == storedHash
to
import bcrypt
if bcrypt.hashpw(submittedPassword, storedHash) == storedHash
etc.
The libraries already manage parsing the salt, storing the difficulty parameter, etc.
posted by introp at 12:58 PM on February 19, 2015 [2 favorites]
The standard nowadays is bcrypt. It's been around a long time and is well-analyzed. It's probably marginally more secure than PBKDF2 (more resistant to attacks like GPU parallelization), though NIST deems PBKDF2 sufficient if the difficulty parameter is set right. scrypt may be even more secure (more resistant to small-memory FPGA/ASIC attacks that a wealthy or state actor might use) but it's also new enough that it's still viewed with some skepticism.
I mean, other than the migration of old password fields to new ones, the changes in using one hasher versus another is going to be something like changing:
import hashlib
if hashlib.sha256(userSalt . submittedPassword).digest() == storedHash
to
import bcrypt
if bcrypt.hashpw(submittedPassword, storedHash) == storedHash
etc.
The libraries already manage parsing the salt, storing the difficulty parameter, etc.
posted by introp at 12:58 PM on February 19, 2015 [2 favorites]
I also want to add my voice to the others that say you should use bcrypt. Not so much for the sake of metafilter accounts in and of themselves, but instead for potential password re-use situations. (username,email,paypal account,password) is a pretty powerful set of information to have if people aren't 100% fastidious about avoiding password reuse.
Here is an guide to using bcrypt in ColdFusion.
The library mentioned even includes a checking function which handles all the salt, etc details, and does checking in constant-time. I can't think of a scenario where timing information would be useful when hashes are compared, but leaking as little information as possible is always best.
posted by grandsham at 1:30 PM on February 19, 2015 [1 favorite]
Here is an guide to using bcrypt in ColdFusion.
The library mentioned even includes a checking function which handles all the salt, etc details, and does checking in constant-time. I can't think of a scenario where timing information would be useful when hashes are compared, but leaking as little information as possible is always best.
posted by grandsham at 1:30 PM on February 19, 2015 [1 favorite]
Thanks for the hashing info, introp. We'll take a look at moving over. The version of ColdFusion we're running doesn't have bcrypt built in—so there's a bit more involved. But the link grandsham mentioned has information about adding it.
posted by pb (staff) at 1:51 PM on February 19, 2015 [4 favorites]
posted by pb (staff) at 1:51 PM on February 19, 2015 [4 favorites]
Yeah, we'll consider switching to bcrypt. There was no support for it for ColdFusion at the time we changed our system in 2007 and sha-256 was pretty good at the time.
The migration is a big project. It's a pain in that there's no easy options and we might have to do a "one day everyone is force-logged out and has to pick a new password" method to get their passwords stored in a new system since the old one is a one-way salt that can't be migrated over. This would mean probably weeks of zillions of people needing us to identify and verify their identity so we could update their emails and they could request a new password. There are ways we could keep both systems in place for some overlap period, perhaps over the course of a few months you get a top banner saying update your password that doesn't go away until you do it, but at some point we'd need to cut it off and force anyone that didn't do it to request a password change.
We'll start working on it and try and come up with the least disruptive way to do this.
posted by mathowie (staff) at 1:56 PM on February 19, 2015 [8 favorites]
The migration is a big project. It's a pain in that there's no easy options and we might have to do a "one day everyone is force-logged out and has to pick a new password" method to get their passwords stored in a new system since the old one is a one-way salt that can't be migrated over. This would mean probably weeks of zillions of people needing us to identify and verify their identity so we could update their emails and they could request a new password. There are ways we could keep both systems in place for some overlap period, perhaps over the course of a few months you get a top banner saying update your password that doesn't go away until you do it, but at some point we'd need to cut it off and force anyone that didn't do it to request a password change.
We'll start working on it and try and come up with the least disruptive way to do this.
posted by mathowie (staff) at 1:56 PM on February 19, 2015 [8 favorites]
The way we do it is to add a password version column. Version 1 is SHA256 and version 2 is bcrypt. When you login with a version 1 password, we verify it using SHA256, then hash it using bcrypt and change your password version to 2.
posted by smackfu at 1:59 PM on February 19, 2015 [10 favorites]
posted by smackfu at 1:59 PM on February 19, 2015 [10 favorites]
The lazy way would be to just generate bcrypt hashes of all the old sha-256 hashes (maybe along with a new salt, although I'm not sure that matters). When a password is sent, you compare bcrypt(sha256(plaintext, oldsalt), newsalt) with your new hash. Clunky, but you don't need to know the existing passwords to implement it.
posted by figurant at 2:04 PM on February 19, 2015 [1 favorite]
posted by figurant at 2:04 PM on February 19, 2015 [1 favorite]
Yeah, the last time I had to do a pw scheme migration was very much like what smackfu describes: the hash prefix identifies the hashing algorithm (a la passwd).
and the "old password stuff" path migrates old passwords. So at the time of first login after the switchover, the submitted passwords get checked against the old hash, then the hash field is updated with
And at no point did you have to ask for or store their password outside when you already are. :) The user never knows their password is now stored more-securely and you at least protect recent users. If you choose to mass-expire pre-bcrypt passwords at some later point, that's an orthogonal problem.
posted by introp at 2:08 PM on February 19, 2015 [2 favorites]
if (hash.startswith('v2magic$')) do_new_password_stuff(...) else do_old_password_stuff(...)and the "old password stuff" path migrates old passwords. So at the time of first login after the switchover, the submitted passwords get checked against the old hash, then the hash field is updated with
bcrypt.hashpw(submittedPassword, bcrypt.genesalt(difficulty))And at no point did you have to ask for or store their password outside when you already are. :) The user never knows their password is now stored more-securely and you at least protect recent users. If you choose to mass-expire pre-bcrypt passwords at some later point, that's an orthogonal problem.
posted by introp at 2:08 PM on February 19, 2015 [2 favorites]
Good news, everyone. MetaFilter is secure.
I know this because I just tried to log in as user mathowie, and all of these possible passwords failed:
- password
- iamthehowie
- firstuser
- votewarren2016
- godofmetafilter
- plateofbeans
- thisismineallmine
- kingmod
- catscanner
- scannerofcats
- zuckerbergpleasebuymetafilterforabilliondollars
So, MetaFilter is tighter than the Kentucky State Budget. Y'all sleep with no worries, now.
posted by Wordshore at 3:46 PM on February 19, 2015 [8 favorites]
I know this because I just tried to log in as user mathowie, and all of these possible passwords failed:
- password
- iamthehowie
- firstuser
- votewarren2016
- godofmetafilter
- plateofbeans
- thisismineallmine
- kingmod
- catscanner
- scannerofcats
- zuckerbergpleasebuymetafilterforabilliondollars
So, MetaFilter is tighter than the Kentucky State Budget. Y'all sleep with no worries, now.
posted by Wordshore at 3:46 PM on February 19, 2015 [8 favorites]
Just curious: do you have "real names" for pre-$5 accounts? I presume that all paid entries would have someway of gathering an identity, but it's been so long now that I can't remember if we had to give names when we signed up---I'm one of the 20/day lotto folks.
You have an email for me on file for sure, but an actual name? I'm curious.
posted by bonehead at 3:47 PM on February 19, 2015
You have an email for me on file for sure, but an actual name? I'm curious.
posted by bonehead at 3:47 PM on February 19, 2015
pb, the attitude was more against the idea every site dev should roll their own crypto protocol from basic primitives. But yeah I didn't communicate that well. And I can see how you might not have any choice on a minor platform like coldfusion.
posted by ryanrs at 3:49 PM on February 19, 2015
posted by ryanrs at 3:49 PM on February 19, 2015
I'd be especially tickled if you guys supported two factor with Google or Facebook.
OpenID has been asked about a couple of times, but the consensus seems to be that it would be a lot of work for not a lot of win. I was kinda excited about the possibilities a few years ago when it looked like a federated log-in system might actually take off, but it doesn't seem to have gone anywhere.
posted by bonehead at 3:52 PM on February 19, 2015 [1 favorite]
OpenID has been asked about a couple of times, but the consensus seems to be that it would be a lot of work for not a lot of win. I was kinda excited about the possibilities a few years ago when it looked like a federated log-in system might actually take off, but it doesn't seem to have gone anywhere.
posted by bonehead at 3:52 PM on February 19, 2015 [1 favorite]
All this encryption stuff is off topic. What I want to know is what will happen to the tasteful nudes I send the mods every president's day if there is a data breach!
posted by Literaryhero at 3:59 PM on February 19, 2015 [3 favorites]
posted by Literaryhero at 3:59 PM on February 19, 2015 [3 favorites]
That does raise the issue of notification and disclosure in the case of a breach. Does metafilter have a policy or internal plan for that?
posted by ryanrs at 4:03 PM on February 19, 2015
posted by ryanrs at 4:03 PM on February 19, 2015
ryanrs: "Does metafilter have a policy or internal plan for that?"
I'm guessing that Metafilter has neither a formal disaster recovery plan nor a formal business continuity plan. Which makes sense for a business with less than ten employees.
posted by double block and bleed at 4:44 PM on February 19, 2015
I'm guessing that Metafilter has neither a formal disaster recovery plan nor a formal business continuity plan. Which makes sense for a business with less than ten employees.
posted by double block and bleed at 4:44 PM on February 19, 2015
Case sensitive, Wordshore. You should have tried KingMOD.
posted by maryr at 5:05 PM on February 19, 2015 [1 favorite]
posted by maryr at 5:05 PM on February 19, 2015 [1 favorite]
I don't know if anyone else noticed, but in that 2007 post, Atwood also recommends bcrypt, not SHA256, at the end.
At the same time how much is it your responsibility to shore up your password system just because people might be protecting data elsewhere with the same passwords? What's the standard nowadays?
I think that, unless you tell people when they sign up that there's no guarantee that their password won't get out, a web site should apply standard measures like bcrypt salting.
From an absolute logical correctness point-of-view, yes, it is the users' fault for using the same password twice instead of getting something like 1Password or one of those open source hashing password generators, but the reality is that even reasonable competent users of the web are just not that vigilant about that stuff. Whatever we know about educating people about security today just doesn't work, so along the lines validating their form input, it's better for the web as a whole if software protects passwords.
posted by ignignokt at 5:21 PM on February 19, 2015
At the same time how much is it your responsibility to shore up your password system just because people might be protecting data elsewhere with the same passwords? What's the standard nowadays?
I think that, unless you tell people when they sign up that there's no guarantee that their password won't get out, a web site should apply standard measures like bcrypt salting.
From an absolute logical correctness point-of-view, yes, it is the users' fault for using the same password twice instead of getting something like 1Password or one of those open source hashing password generators, but the reality is that even reasonable competent users of the web are just not that vigilant about that stuff. Whatever we know about educating people about security today just doesn't work, so along the lines validating their form input, it's better for the web as a whole if software protects passwords.
posted by ignignokt at 5:21 PM on February 19, 2015
Just curious: do you have "real names" for pre-$5 accounts?
Not for most, I think. We don't have yours, just your email.
posted by LobsterMitten (staff) at 7:34 PM on February 19, 2015 [1 favorite]
Not for most, I think. We don't have yours, just your email.
posted by LobsterMitten (staff) at 7:34 PM on February 19, 2015 [1 favorite]
I've had a "yourname.com" domain for a long, long time and use a password manager app; I somehow got into the habit of not only using a unique password for every site, but a unique email address. It turns out that the per site unique email address is the internet equivalent of radioactive dye in a CT scan - I suddenly can see exactly who is selling my email address and sometimes where/when it is getting exposed in a breach (that may not be reported, or even discovered). It is also fairly depressing when you realize how pervasive the problem is. I applaud pb and matthowie and cortex for having a rational discussion about whether they should be doing something different with respect to how they encrypt passwords. But, if you (the user) reuse passwords across the same user id, your weak link isn't going to be metafilter, it is going to be some *other* website that doesn't have a metatalk or give thoughtful consideration to their encryption algorithms.
posted by kovacs at 7:42 PM on February 19, 2015 [4 favorites]
posted by kovacs at 7:42 PM on February 19, 2015 [4 favorites]
Or other sites where the admins are your hostile adversary. Small time web forums and legal grey-area sites have this happen occasionally, where the sketchy site admin hacks some of their own users' accounts on competing sites because the users reused the same password.
posted by ryanrs at 10:19 PM on February 19, 2015
posted by ryanrs at 10:19 PM on February 19, 2015
Considering the recent issues regarding funding, how much cost is associated with the move? I get a sort of puerile joy at watching people lecture on cryptography in threads like this because doesn't the first rule of password management obviate the benefit of cracking the db? MeFi isn't a bank and huge amount of the data is already publicly available. I don't even know what my MeFi password is - it's whatever LastPass ginned up. I'd rather resources go to mods. I'd also be happy to contribute to single use KS or other fundraiser for this transition for people who worry about potentially sensitive info being de-anonymized (sadly, I can envision a scenario where a handful of GGers go gunning for a single user and everything gets cocked up). As a user, I don't see this as mission critical, but I'm not running the place either.
posted by 99_ at 10:24 PM on February 19, 2015
posted by 99_ at 10:24 PM on February 19, 2015
I'm glad passwords are being encrypted, and I'd really like to have my MeFi password encrypted too. It's "Password1234" - if someone could encrypt that, I'd feel a lot better. But don't encrypt it as something really complex or weird, I still gotta remember it! No but I use that password everywhere, so something really encrypted but also really simple would be awesome - thanks.
posted by the quidnunc kid at 11:14 PM on February 19, 2015 [11 favorites]
posted by the quidnunc kid at 11:14 PM on February 19, 2015 [11 favorites]
Quidnunc kid, I've encrypted your password to 4321nataSdrowssaP. Hope that helps!
posted by ardgedee at 2:23 AM on February 20, 2015 [3 favorites]
posted by ardgedee at 2:23 AM on February 20, 2015 [3 favorites]
Ok, thanks!
posted by the quidnunc kid at 2:39 AM on February 20, 2015 [4 favorites]
posted by the quidnunc kid at 2:39 AM on February 20, 2015 [4 favorites]
Thanks from me too!
posted by the quidnunc kid at 2:42 AM on February 20, 2015 [10 favorites]
posted by the quidnunc kid at 2:42 AM on February 20, 2015 [10 favorites]
Yep, works for me as well. Great job!
posted by the quidnunc kid at 2:42 AM on February 20, 2015 [13 favorites]
posted by the quidnunc kid at 2:42 AM on February 20, 2015 [13 favorites]
the quidnunc kid: "I'm glad passwords are being encrypted, and I'd really like to have my MeFi password encrypted too. It's "Password1234" - if someone could encrypt that, I'd feel a lot better. But don't encrypt it as something really complex or weird, I still gotta remember it! No but I use that password everywhere, so something really encrypted but also really simple would be awesome - thanks."
This should be easy to remember:
posted by double block and bleed at 6:45 AM on February 20, 2015
This should be easy to remember:
[3] pry(main)> BCrypt::Password.create("Password1234" + "VOTE #1 QUIDNUNC KID")
=> "$2a$10$i.j3ztXoWm7h.scanabqzu4OapXHLsU5s6Ja2GQDidCc7CO.X3bUO"
NOTE: This is just for lulz. Don't do real password hashing like this.posted by double block and bleed at 6:45 AM on February 20, 2015
I think in a way the greater fear here would be an admin account getting hacked and that being used maliciously to do things like dump the DB or delete all files.
I've, as a thought exercise, wondered what this place would be like if it were to zero out and start over from scratch. Like say a catastrophic data loss without backup. All images, all CSS, all templates, users, and databases. Gone.
How many people would sign back up to start creating new content? Would the same choices be made on rebuilding the back end (Cold Fusion makes sense from a historical context, but if someone were to try to rebuild metafilter today I doubt it'd be picked)? How much would traffic drop off? Would the price of admission be $5 again? Would people who claimed to be here previously be exempted? Would people even bother to rebuild? What style and look changes would be made? How long would it take to spin a site back up?
posted by cjorgensen at 7:31 AM on February 20, 2015
I've, as a thought exercise, wondered what this place would be like if it were to zero out and start over from scratch. Like say a catastrophic data loss without backup. All images, all CSS, all templates, users, and databases. Gone.
How many people would sign back up to start creating new content? Would the same choices be made on rebuilding the back end (Cold Fusion makes sense from a historical context, but if someone were to try to rebuild metafilter today I doubt it'd be picked)? How much would traffic drop off? Would the price of admission be $5 again? Would people who claimed to be here previously be exempted? Would people even bother to rebuild? What style and look changes would be made? How long would it take to spin a site back up?
posted by cjorgensen at 7:31 AM on February 20, 2015
Next time, we definitely won't use the "best of the web" tagline. Cripes, the grief that's caused.
posted by Chrysostom at 7:52 AM on February 20, 2015 [1 favorite]
posted by Chrysostom at 7:52 AM on February 20, 2015 [1 favorite]
How many people would sign back up to start creating new content?
How many people would sign back up... using other peoples' usernames...
posted by EndsOfInvention at 8:12 AM on February 20, 2015 [1 favorite]
How many people would sign back up... using other peoples' usernames...
posted by EndsOfInvention at 8:12 AM on February 20, 2015 [1 favorite]
Hrrrrhg...
posted by Zombie Bondcliff at 8:14 AM on February 20, 2015 [5 favorites]
posted by Zombie Bondcliff at 8:14 AM on February 20, 2015 [5 favorites]
If cjorgensen's thought exercise were to happen, I would sign back up, but only as a sockpuppet. My big concern would be my favorites. Is there a backup for those at least?
posted by 724A at 8:42 AM on February 20, 2015
posted by 724A at 8:42 AM on February 20, 2015
Yes, we back up the entire database. You can also save favorites yourself locally. There's an Export Your Favorites option at the bottom of Preferences.
posted by pb (staff) at 8:47 AM on February 20, 2015 [1 favorite]
posted by pb (staff) at 8:47 AM on February 20, 2015 [1 favorite]
In the post-apocalyptic warzone of the future, favorites will be the only hard currency.
posted by Chrysostom at 8:50 AM on February 20, 2015 [4 favorites]
posted by Chrysostom at 8:50 AM on February 20, 2015 [4 favorites]
Hey I just want to toss props out there to mathowie and PB for taking the bcrypt suggestion and looking into it. The company I work for did a migration of over 3 million passwords to bcrypt, it was an effort for sure, but it was able to be done without causing havoc.
posted by Annika Cicada at 9:56 AM on February 20, 2015 [3 favorites]
posted by Annika Cicada at 9:56 AM on February 20, 2015 [3 favorites]
my password is smocksmocksmock
posted by quonsar II: smock fishpants and the temple of foon at 12:27 PM on February 20, 2015
posted by quonsar II: smock fishpants and the temple of foon at 12:27 PM on February 20, 2015
My password isn't TheGrumpiestUserOnMetaFilter
But it probably should be.
posted by Wordshore at 2:18 PM on February 20, 2015
But it probably should be.
posted by Wordshore at 2:18 PM on February 20, 2015
EndsOfInvention: "How many people would sign back up... using other peoples' usernames..."
Based on experience of when MetaChat started up, quite a few :-(
ryanrs: "Or other sites where the admins are your hostile adversary. Small time web forums and legal grey-area sites have this happen occasionally, where the sketchy site admin hacks some of their own users' accounts on competing sites because the users reused the same password."
Or my bank, which has such restrictive rules for passwords to use online banking (must be 6 characters, all upper case, must include 1 and only 1 number, no other characters allowed) and forces people to use an on-screen keyboard that leaves a box around each character you click until you click the next one (so anyone that can see your screen can easily see the password you're entering). I'm far from any kind of expert in this stuff, but that has to dramatically reduce the possible number of passwords someone would have to try. Combined with people's determination to use the 'one true password' everywhere, I shake my head every time I log in there.
posted by dg at 2:21 PM on February 20, 2015
Based on experience of when MetaChat started up, quite a few :-(
ryanrs: "Or other sites where the admins are your hostile adversary. Small time web forums and legal grey-area sites have this happen occasionally, where the sketchy site admin hacks some of their own users' accounts on competing sites because the users reused the same password."
Or my bank, which has such restrictive rules for passwords to use online banking (must be 6 characters, all upper case, must include 1 and only 1 number, no other characters allowed) and forces people to use an on-screen keyboard that leaves a box around each character you click until you click the next one (so anyone that can see your screen can easily see the password you're entering). I'm far from any kind of expert in this stuff, but that has to dramatically reduce the possible number of passwords someone would have to try. Combined with people's determination to use the 'one true password' everywhere, I shake my head every time I log in there.
posted by dg at 2:21 PM on February 20, 2015
You could try doing a staged deadline with a rolling window across the user base to try to rate-limit the amount of mod work involved in switching over to bcrypt. Hash everyone's user numbers, put the hashes in a big sorted list, and then move through the list in order asking people to switch their passwords. (The hashing produces a random shuffle of all of the user id's, to avoid getting hot spots of active users.) The rate at which you move through the list should approximately determine the rate at which you get user emails.
posted by kaibutsu at 10:42 AM on February 21, 2015
posted by kaibutsu at 10:42 AM on February 21, 2015
Aren't they more likely to be able to document our activity from the browser end of data capture and collection?
posted by infini at 8:28 AM on February 22, 2015
posted by infini at 8:28 AM on February 22, 2015
Yes, though the OP seems more concerned about a site security breach and public dump specifically revealing their personal info and anon questions to the general public rather than mass surveillance by intelligence agencies/corporations/targeted attacks.
Regarding the latter, this nice EFF graph shows a simplified view of who can know what under what conditions. Entities able to see both "User/PW" and "Data" can link anon questions to the users since they must be logged in when posting, even if MetaFilter does everything correctly on their end and doesn't cooperate with malicious actors.
posted by Bangaioh at 9:03 AM on February 22, 2015 [2 favorites]
Regarding the latter, this nice EFF graph shows a simplified view of who can know what under what conditions. Entities able to see both "User/PW" and "Data" can link anon questions to the users since they must be logged in when posting, even if MetaFilter does everything correctly on their end and doesn't cooperate with malicious actors.
posted by Bangaioh at 9:03 AM on February 22, 2015 [2 favorites]
Yes, to be clear, I'm asking about consequences that are outside of my control.
I can practice excellent security hygiene: site-specific password, site-specific anonymous email address, obscured browsing habits such that large-scale tracking is ineffective. But if my real name is associated with my account, then my anonymity is at threat, and I can't fix it.
It would be nice if this kind of personal data would be flushed after a probationary period. Like, I paid my registration fee for this account and for two years have not misused it. Perhaps as a reward for good behavior you could delete my real name and PayPal email address?
posted by mf_ss at 9:12 PM on February 23, 2015
I can practice excellent security hygiene: site-specific password, site-specific anonymous email address, obscured browsing habits such that large-scale tracking is ineffective. But if my real name is associated with my account, then my anonymity is at threat, and I can't fix it.
It would be nice if this kind of personal data would be flushed after a probationary period. Like, I paid my registration fee for this account and for two years have not misused it. Perhaps as a reward for good behavior you could delete my real name and PayPal email address?
posted by mf_ss at 9:12 PM on February 23, 2015
Perhaps the converse could also be true? Misbehave enough and your real name and e-mail address gets appended to every comment you make here.
posted by dg at 2:24 PM on February 24, 2015
posted by dg at 2:24 PM on February 24, 2015
I know I don't actually need to say "no", dg, but for posterity: no, gosh no.
mf_ss, zapping some of your data for you as a specific request because of some concrete privacy concerns about your identity and your relationship to the site is likely doable, and you're welcome to follow up with us at the contact form about it.
Zapping everybody's in general is not so much; that's information that we've had to actively use, over a longer time frame, to resolve site issues ranging from spammery bullshit to suicide scares, and chucking it out would make us less able to do the job we do here.
posted by cortex (staff) at 2:36 PM on February 24, 2015
mf_ss, zapping some of your data for you as a specific request because of some concrete privacy concerns about your identity and your relationship to the site is likely doable, and you're welcome to follow up with us at the contact form about it.
Zapping everybody's in general is not so much; that's information that we've had to actively use, over a longer time frame, to resolve site issues ranging from spammery bullshit to suicide scares, and chucking it out would make us less able to do the job we do here.
posted by cortex (staff) at 2:36 PM on February 24, 2015
Sorry, one of my brain farts got out before my sensible side could grab it :-( Just to be clear - I'm not seriously suggesting that ever happen.
posted by dg at 2:42 PM on February 24, 2015
posted by dg at 2:42 PM on February 24, 2015
You are not logged in, either login or create an account to post comments
posted by restless_nomad (staff) at 10:43 PM on February 18, 2015 [2 favorites]