"There were occurrences of Lish passwords in clear text in our database."
I think that this is what's most criminal about the whole event. It's probably safe to assume that "there were occurances of Lish passwords in clear text..." is a euphemism for "we stored all Lish passwords in cleartext."
Simply invalidating these is probably not enough. It's very likely that people reused their root login passwords as their Lish passwords, meaning that Linodes running without firewalled sshd are potentially vulnerable.
I hope Linode communicated who had "the occurrences" of compromised cleartext Lish passwords, so that those users could take appropriate action.
> "It's probably safe to assume that 'there were occurrances of Lish passwords in clear text...' is a euphemism for "we stored all Lish passwords in cleartext."
This borders on libelous, in my opinion. If all Lish passwords had been stored in the clear, I think they would have said that. They've been pretty specific in the rest of the update.
They say they have "invalidated all affected Lish passwords effective immediately". I just logged in to Lish via SSH using the new password I had set on Friday, so I guess mine at least wasn't one of the "occurrences"....
Lish passwords in the clear might have been in support tickets stored in the same database, or chat logs.
Also: "It's very likely that people reused their root login passwords as their Lish passwords..."
Really? I guess it's never a good idea to doubt people's capacity for stupidity, but this seems very obviously a bad idea. Hopefully this isn't so common as to be "very likely".
I've been a Linode customer since the start of 2007 and my biggest worry right now is this...
> Credit card numbers in our database are stored in encrypted format, using public and private key encryption. The private key is itself encrypted with passphrase encryption and the complex passphrase is not stored electronically.
By not providing further clarification that the private key was stored outside that compromised host in that update, you can read between the lines that they are trying hard not to address that particular issue.
I really don't want to assume that the attacker can now brute force the private key's passphrase, and it might not take long if that "complex" passphrase was a word out of /usr/share/dict/words.
Or worse, that the billing process was monitored via the compromised network, RAM, or a key logger - to get the unencrypted private key or it's passphrase.
Once they give the private key passphrase out there would be no need for us to judge for ourselves. The hackers would have everyones credit card information at that point.
I recommend not bothering. Liability for fraudulent CC activity (in the US) is very low (max $500), and banks never enforce the liability for two reasons: 1) it's easier for them to chargeback the transaction to the vendor, thus they're not out of pocket, and 2) it causes customers to leave for a provider that doesn't hold them liable.
How much of your time spent chasing down and changing a CC number is worth a maximal risk of $500 with a vero low probability of occurring?
I'm pretty sure you're off by a factor of ten. If someone makes fraudulent charges with your credit card, your maximum liability is $50, and you'll only have to pay that if the charges occur after you've reported the card stolen. (There are different rules for debit cards, that doesn't apply here.)
The lish passwords are the easiest to abuse immediately, but the larger impact is on all the user accounts with weak reused passwords. While all of the manager passwords were reset, each VM's root password was not. Once a hashed password is cracked their root password is vulnerable (if it was reused). And that's probably a lot more people than had exposed lish passwords.
Everyone should go reset their virtual machine's root password if they reused them.
Exactly! I'm pretty sure it was all Lish passwords. Yesterday the news was all focused on the credit card information but now it makes sense why Lish passwords were not working (when I was 100% sure I had it correct--Friday's email said nothing about lish iirc). Interestingly I even mentioned this as part of a ticket and they brushed it off as nothing... hmm.
I think that this is what's most criminal about the whole event. It's probably safe to assume that "there were occurances of Lish passwords in clear text..." is a euphemism for "we stored all Lish passwords in cleartext."
Simply invalidating these is probably not enough. It's very likely that people reused their root login passwords as their Lish passwords, meaning that Linodes running without firewalled sshd are potentially vulnerable.
I hope Linode communicated who had "the occurrences" of compromised cleartext Lish passwords, so that those users could take appropriate action.