49 comments

[ 5.4 ms ] story [ 152 ms ] thread
So they had Mult Factor Authentication, OTP, and Yubikey all and they still used his mother's actual maiden name and place of birth. With all of that you would think they would do what everyone else does or should do on that. !@3f49 for place of birth and Erjsh99 for her maiden name. Using real information is just a weak point in a weak system.
The problem with the latter would be when you call in and try to convince some service rep that your mother's name is actually Erjsh99.
As long as it matches the name they have on record, why would they care?
Agreed; I'm using the same approach of my own 'recovery keys'. Usually it's possible to provide them in a recovery UI online. And in the case you need to talk to an actual human being, it's easy enough to explain the reason behind it.
They probably shouldn't but I had an instance with an ISP back in the day where they wouldnt accept my answer to a security question because the answer was ridiculous. The question was "in what city was your high school?" I put "Upyourassville." The ISP thought there was a problem and wouldnt accept the answer. These days I use my grandmother's maiden name as my mother's maiden name to answer these questions. There are people in my own family who dont know the answer to that.
I actually see that as a plus. If for whatever reason I forgot my own password and can't get onto my account it should be difficult. More so if the guy on the other end should be doubly sure that I am the real account holder if my esoteric answers match up.
There was a time in the early days of the 'net where using your actual name (and by extension your mothers maiden name) would have been considered perverse- "It's the internet, we can be whoever we want to be". Sadly the powers that be have shifted that away to the point where you are a misfit if you are using accounts that are not linked in some way.
I use gibberish for the answers.. but once (forgot the name of the company.. a few years ago) I lost the answer to the question... so I said "I can't find the answer, but I know it's a bunch of random letters"... and the customer service rep, said 'Ok', and accepted it as the answer.

So maybe use real words in the future

Reading the article, I don't think bitInstant ever gave that information as valid answers to security questions. The attackers convinced site5 to accept that information as security questions and answers.
Damn, that must be frustrating as hell when a third party fucks you like that. And why is it always the DNS providers. Shouldn't that entire industry know they are target #1 by now?

On a tangential note, I hate security questions. I do not understand the need for them, or how they keep anything secure, when the questions they asks are always public knowledge.

Until they start getting held liable, why should they care?
"I hate security questions. I do not understand the need for them, or how they keep anything secure, when the questions they asks are always public knowledge."

Like with most things, security questions create a facade of security. Just like the "at least one lower case letter, one uppercase letter, one number, and one non-alphanumeric character" requirement of some sites: more often than not, the resulting password is "easier" to guess (many people put the numbers at the end, etc)

there's no reason for you to give them your actual mother's maiden name though, just tell them M)z&1<$Ccy(i]Kg&&dp` or something
That's a great idea for online services, assuming that they don't have strict validatation ("your mother's maiden name can not contain symbols"). I'm not sure it would work as well with companies who call you though.
That's right: someone who knows their credentials will be the focus of deliberate attacks should never use truthful personal details in response to these "security questions." Perhaps this is a "best practice" for anyone involved in such sensitive situations, even while the true best practice would be for sites to not allow password resets using such unreliable authenticators.
This, incidentally, makes for fun conversations with phone support.
While I agree that they are useless, I don't mind the security questions that are used to reset one's password, provided that proof of email ownership is required. These are just a minor nuisance.

The dangerous ones such as this allow someone to use the security questions in place of your password. These are less secure than if you were to use your place of birth and address as your password.

Their thought process probably goes something like "we can't have users giving us their password over the phone, anyone could overhear that and they would think it is insecure. Lets have them give us something less confidential instead".

Services like this that require verbal authentication via the telephone should generate a passphrase and email it to their uses upon signup.

So, when signing up, how do you know what the security question is going to be used for? And how do you know that won't change?

Any service that is sensible enough to give you that information will hardly make use of "security-questions" in the first place...

A lesson we can take from this is just because they are supposed to be security questions based on private and personal information, doesn't mean you should play along.

Why should the answer to where me and my spouse met really be where we met? Why couldn't my answer be where Lucille Ball met Ricky Ricardo? Why couldn't my childhood street address be Evergreen Terrace?

Add a layer of security by creating an entirely different alter ego with a whole history behind it, and use their birthday, maiden name, etc, instead of what somebody can look up in public records, or find out from people close to you.

I usually just generate additional random passwords to put in those fields, and store those in the password manager right alongside the primary password.

Sure it defeats the purpose of those fields as a secondary layer if you should lose the password (if I lose everything in my password manager I have bigger problems) but at least an attacker has no more chance of guessing those than of guessing the primary password.

Is there a best practice for keeping a secure copy of one's password manager database? USB key in a safe? Single use Dropbox with an anonymous email? Encrypted file container by yubikey?
1password integrates with dropbox so your (encrypted) passwords are available on all systems that you install the 1password client on.
I humbly suggest leaving it with a friend but only if the friend understands security sufficiently well, e.g., a competent professional sysadmin.
They should get BitInstant added to the HSTS list. It'll prevent attacks like this.
HSTS would not make a difference here. They redirected the DNS for email to take over the email accounts.
Are there any monitoring services, like Pingdom, that do external 3rd party auditing of current DNS endpoints for a domain and offer alerting whenever a change is made?

That service (being external from the registrar or DNS provider) seems sorely needed by everyone in our industry because this method of attack is starting to become the standard.

I have very little sympathy: "Reached Thursday, a VirWox representative said that the exchange has had multi-factor authentication since September 2012. “Bitinstant was not using it (they learned and do now),” the representative said in an email message."

If you're going intentionally fuck yourself and your customers over by not using real multifactor authentication (not just "a password and some security questions"), then I don't even know what to say. At this point it's on par with having a startup and not having any on-call tax or legal guy-- the inherent ignorance is almost incomprehensible.

From the comments section of the linked blog post comes this quote (apparently) from Ben, the CEO at Site5:

To be rather blunt you should have better security questions. You should always put in a custom answer, for example I might use the question mother's maiden name and then the answer is "L@J-289098=a9jaosdjf" which I keep in an encrypted text doc or ecrypted note in 1Password.

Not a bad point.

Maybe Site5 should ask better security questions then. If they want users to enter what is effectively a password for "Mother's maiden name" they should just ask for a security password.
I agree that the true-to-life reminder questions are probably an outdated model. However there's nothing intrinsically wrong with the maiden name question. There is no server-side code checking in with your mother or running her middle name against a federal database, you can enter whatever you want in the box. Surely people who are savvy enough to be trading in Bitcoin realize this.

  However there's nothing intrinsically wrong with the 
  maiden name question.
Asking users to enter their mother's maiden name, when you actually think they certainly shouldn't do that, then blaming your customers for having used their maiden name, seems like an odd way of doing it.

If mother's maiden name isn't a good enough security question, stop asking it! And we all know it isn't a good enough security question.

Yes

It's a pain, but I don't trust this "Mother's Maiden name" invention.

Problem is remembering this (and some offline systems have it as well, oh well)

So if you think I'm going to put the actual name there you're wrong. Maybe not +@sfghh#54$=24 but something different.

If that is the CEO of Site5, I would never use that company again, and I publicly laugh at their audacity in denying their team's incompetence.

Yes. Not using true information is a good practice for security questions. If the CEO of a technical company thinks so, as well, then don't fscking ask me for my mum's maiden name!

1) Ask for a backup password and specify it should be kept offline.

2) Tell users to lie on the maiden name question.

Do NOT point the finger after a breach at your company to one of your customers. Terrible practice.

To paraphrase: the question 'What is your mother's maiden name?' is intrinsically insecure as a security measure; instead of answering it directly, make up some unguessable string that has nothing to do with the question.

Sound advice, but... but... but.....

This is his own website using this as a security question!

It's about the target audience. Most normal people aren't going to be using their registered domain name for extremely high-value and highly targeted stuff, and they'll be upset if you say "Oh, you forgot your random string? Well, I guess you're screwed bub, sorry". But if you're doing something involving btc, you should be conscious enough to know "maybe I shouldn't put the security of my account behind easily locatable public info like the name of myself or family members".
1) They shouldn't be asking this type of question in the first place. They're promoting insecure practices, and can't seriously expect all their customers to know they should lie in their answers.

2) Knowing the answers to those questions shouldn't allow an attacker direct access to the account. It should initiate a password reset via email.

re: 2- the attackers apparently had an email address very similar to the victim's email. Most likely just convinced the tech support that the victim's email addr had a typo.
Either way it's Site5's fault. They need to be aware of social engineering attacks.
At that point, what is the point of the secret question in the first place? If I lose my password, I probably also lost my security answer, and even if they're stored in separate places, then isn't it just another vector of attack which does nothing for my security anyway?
This attack may have been one of the problems, but there is some indication that BitInstant has deeper financial issues than this post would indicate. Perhaps a $12K hit would make a site like Bitinstant go silent and not process most transactions for weeks on end, but if that is the case then they are woefully underfunded.

https://bitcointalk.org/index.php?topic=128314.1380

At various points in this thread, people posted saying the company even admitted privately to them that they did not have funds to process orders. FYI their most popular feature, Cash to Bitcoin Address, is still offline - presumably because they have no Bitcoins to deliver. The only indication that they have any funds at all is on the home page of Btc-e.com, which indicates (as of right now) that they have a $475 reserve at the site.

I can see that some people have had serious problems with them. For what it's worth, though, I used their service for the first time last week. It worked fine, and only took a few moments for them to complete the transaction after I deposited the cash.
Same here. I used the Moneygram service at a CVS, and by the time I got home they had already sent the bitcoins. Great and prompt service. I hope they get back on their feet soon.
Whatever happened to "Name your own security question?" You used to be able to do that with many services, but now it seems every service I use forces me to a small set of easily guessed questions.

A security feature that requires me to lie to maintain its security is NOT a good security feature.

It all depends on your risk profile as to whether this type of authentication is sufficient. Sites doing anything remotely involving money are at greater risk of being hit therefore their security needs to account for this. Putting passwords on the internet which is equivalent to having details you use for authentication in public records, would be a bit silly.

I don't buy the argument that a security system you need to lie on is not a good one. Security is an onion, it comes with many layers you can't assure a third party service easily so you've got to add layers to that onion, even if that means being a liar.

That said security is also a trade off with the lowest common denominator - user.

The russian origin of the attack and the perseverance shown by "them" may be a sign that international organized crime is very much interested in bitcoins now.
Always allow your users to opt out of a security question during signup. Give them a friendly warning that you won't be able to assist with lost accounts, but allow them to make that choice.