That technical explanation sounds almost like word salad. How did a DDoS hit your SAN in the first place and how did your SAN blowing up allow a compromise?
If you are new to bitcoin-related sites, you might find this story close to legitimate. But anyone that reads the article will see there is this "basic" flaw mentioning that DDoS attacks gave access to the server. If you read past (paid) articles about this very same service, you will see claims about how secure the system is, and how expert everyone that developed it is. The same was claimed by inputs.io, I'm sure you have read about that story earlier.
The thing is, if you want to use bitcoin, you cannot trust third parties to hold your coins for you. If you want to support bitcoin in your business, you cannot trust other sites to handle the payment for you. Yes, it is not convenient. But you have everything available to handle this yourself and, yes, you will need someone competent to do that for you if you are not into it. Bitcoin is not meant for the average user or the unaware merchant and it might never be, people need to start accepting this fact.
Reading between the lines you are suggesting that this vector of attack had to come internally from BIPS? Given how much bitcoin price soared it is not unreasonable to question whether one of the engineers there had his price named.
I don't think they're suggesting that, more just gross incompetence on the part of the developer, and a little bit of liberty about how "secure" the systems they have created actually are. It's a lot like inputs.io, a web wallet compromised because the developer used Linode to protect millions of dollars. The developer of that particular service paid back about the half the funds then disappeared.
> BIPS was built by passionate bitcoiners and talented developers. BIPS is hosted in our private server facilities. Passwords are stored with a double salted SHA-512 hashing algorithm. Our entire website is protected with AES RIJNDAEL 256 encryption and we have encryption of data traffic with 2048-bit, highest assurance Extended Validation SSL certificate, with 99.9% Browser Recognition.
> BIPS protects your payment information with industry-leading security and fraud protection.
On top of this, our server/database is regularly stored on tape backups. For added security you can also enable Secure Card and Google Authenticator at any time for up to 3 levels of authentication.
Is it just me, or is some excited "Look we encrypt everything, and look, we even use good algorithms and look at those key sizes!" becoming a red flag about the security of a service? Most of the times it seems to be someone being excited about using state of the art encryption and forgetting that encryption is only as hard as the system and the humans surrounding it.
There's a lot of incompetence on display in that technical description.
"Our private server facilities" sounds like they were trying to run their own facility for some misbegotten reason.
"A double salted SHA-512 hashing algorithm" sounds like a weak homegrown password hash. I'm guessing it was something along the lines of SHA512(salt1 + SHA512(salt2 + password)), which is pitifully weak compared to any sort of iterated hash (bcrypt, scrypt, PBKDF2, etc). It could also mean SHA512(salt1 + password + salt2), which would be even worse in a kind of sad, hilarious way.
"AES RIJNDAEL 256 encryption" is a perfectly normal SSL cipher. Referring to it as "RIJNDAEL" is a bit of a tipoff, though: Rijndael is not an acronym, so it shouldn't be capitalized, and it's simply an older name for AES, so it's entirely redundant in this phrase.
"2048-bit, highest assurance Extended Validation SSL certificate" is something you can get from any number of vendors. It isn't actually any more secure than any other SSL certificate.
"Industry-leading security and fraud protection" probably means nothing. Or, at most, possibly that they're using an off-the-shelf fraud detection service like Maxmind - which would have done little to nothing to protect them from a determined fraudster, let alone an attacker.
"Tape backups" just make it sound like they're using equipment from the 90s.
"Secure Card and Google Authenticator" are both decent features to implement, but suggesting that they result in "up to 3 levels of authentication" is amusing. Multiple possession factors ("something you have", like a security token or a cell phone with Authenticator) don't add together; to have three factors, you'd need a knowledge factor (a password), a possession factor, and a biometric factor. And they definitely don't have the last one.
Appearing to be incompetent in some circumstances may be a pretty good cover. If you are a security guard at an art museum, and buddies with some art thieves, then it might be in your best interest to get yourself a reputation for sleeping on the job.
So if he gotten over 50% of stolen funds as his `fee` he could end up ahead? But yeah, given that he paid back half of stolen funds this angle does look weak.
Is it possible to launder stolen bitcoins on Chinese exchange?
Just to clarify, yes, I meant exactly that (and that is why I love this place, people actually get it).
And the inputs.io guy is not even close to paying half to what was "stolen". The inputs.io guy was also running coinlender and other services, which are all gone -- including himself.
How can we be sure that the attack wasn't inspired/originated by the site itself? Similar to how an EVE bank exited with everyone's funds after operating for almost a year[0]
I've heard of DDoS attacks used to divert the admins attention while a real attack is occurring. Also I know packet flooding can cause some network hardware to switch into a lower security mode in an attempt to handle the load. I'm not sure if either of those apply in this case, though. I definitely am not a network or security expert.
Right, they're used as distractions fairly often. The rest of the explanation makes no sense though; that is, I don't see how the DDoS would then "make the system vulnerable" to Bitcoin theft. Unless it was something like where the attackers already had access, but most everything was kept in cold storage and they wanted to force them to move a lot of BTC into their live wallets.
Re: pure magic: perhaps the SAN is willing to talk to whoever sends it packets, and/or to be administered by whoever can enter admin:admin into a poorly-secured web interface as soon as it loses the appropriate connection/reboots due to overload/..?
I agree with my sibling comment that this seems an odd way to install a SAN.
