Apex (17-11-2012)
Not received e-mails like this, but I think I'll change my PW just in case..
How the **** did I miss this topic?
Did Scan at least send out an email to all customers advising them of this breach? Jesus...
As I KEEP SAYING:
Scan and good communication do not happen, they are crap at it!
Good thing i've only been with Scan a couple of years... Do you think they'll let us know if it happens again?
I just changed my password now, after seeing this thread, although it was futile given the breach was in 2007 /facepalm
Can we safely assume our passwords are no longer stored in plain text?
Well my password has now been changed but It does scare me somewhat to think how long ago this happend yet its only being brought to attention 5 years after our details have been flowing freely around the internet.
My account is from '02 so I'm changing both password and security answer. Probably a good idea anyway its been the same for 10 years, oops.
Probably, weather they are hashed with salt is another matter.
Time and time again we hear about password databases getting leaked from companies large and small. Though it is fairly rare to hear about password databases entirely in plain text, it is quite common to hear that the password was encrypted with a reversible cipher, with the key hard coded into the source of the web application, or hashed without salt.
If the password is reversibly encrypted then it may as well be in the clear, because if crackers get in and dump the database, they can just as easily get the source code an use it to decrypt the password DB.
Hashes without salt are only marginally better, when you realise that there are services such as md5decrypter.co.uk that will quite quickly tell you that 286755fad04869ca523320acce0dc6a4 is the md5 hash of "password". (There are other sites for for SHA-1 and SHA-256, and it is fairly easy to obtain large databases of hashes for common passwords, or to build your own).
Even if the user has a hard to guess password that is unlikely to be in any lookup tables, then the hash can still be used to brute force the password. And if the same hash appears in several places then the hackers know it is for the same password. The David Petraeus Scandal has been in the news recently. Apparently his mistress had her google email cracked because she also had a Yahoo account, and the password DB for that was leaked. The SHA1 hash of her password was not in any lookup table, but because she was a important someone took the time (probably about 30 hours on modern GPU accelerated hardware) to brute force the password, and it turned out to be the same as her google one.
Better is to hash each password with a different salt. The salt can be anything, so long as it is unique to each user on the system. By using salt you make sure that identical passwords don't create identical hashes, so big lookup tables become useless. It is still possible to brute force the password of a high value target though.
To prevent brute forcing passwords, a final technique should be used: Repeated hashing.
Hashes like SHA1 are designed to be fast. The designers claim that it cost only 12 or so CPU cycles per byte hashed, so on a modern CPU you can calculate the hash of an 8 char password in nanoseconds. This is good if you want to test the checksum of an ISO you just downloaded but bad if you want to prevent someone from trying out every possible password for someone they are trying to crack.
To prevent this, hashing algorithms like Bcrypt hash the output of the first hash run over, and over again. The idea is that if your web application hashes over and over, perhaps 10,000 times, then it will only take 1/100th of a second, and make no difference to the user experience of the web site or how much CPU load it puts on the server, but it make brute forcing even one password impractical for crackers.
Are you reading Scan web team?
Salts don't really make a difference against targeted exhaustive searches, but like you say they do defeat lookup/rainbow tables and mass bruteforce searches. Ideally, people should use very long passphrases (although some sites have ridiculously short length masks); as xkcd made a point about a while back, a short password like 4h&3d) is very complex to remember but easy to break, while a short sentence is far easier to remember, and far harder to break. Realistically, most people aren't going to do that, so some responsibility is left to websites to harden against attacks.
Bcrypt is just one function; it's not necessarily run multiple times, but it is far slower than traditional hash functions like SHA. However, it's still quite acceptable and common, to run through hash functions a few thousand times; they're still designed to be incredibly strong and resistant to attack, but also to be very fast.
There's really no excuse for storing passwords poorly, whether it's in the clear or using an inadequate function. The cost (computational and monetary) is negligible.
Nope - and a week has passed, so I'll fill in as much of the additional details as I can remember from the phone call I had. My apologies if I get any of this wrong, I was expecting that Scan would have made a statement of some form by now...
Right now I won't release the name of the person who phoned me, but I'm pretty sure you can get in contact if you phone/email Scan's customer services about the the issue.
* Apparently way back when, Scan used to keep all passwords as plain text. This is not new news and is probably no different to how most retailers did things back in the day.
* In something like 2006/2007 they spotted the error in their ways and started encrypting passwords, but only for new customers (that didn't make sense to me either, but whatever). Scan do know exactly when they implemented this policy and which customer would fall under the former category. Apparently all passwords are now encrypted.
* Later in 2007 (I forget the date, but Scan do know exactly when), there was a breach. I also forget the details of this, but it was something like snooping of a between-site or between-database transaction, or a remotely triggered transaction. Scan noticed the activity and terminated it in some fashion.
* The data involved consists of the personal account data (address, telephone numbers, passwords), but not credit card details or order history as these are stored in different databases. I was not clear on whether Scan knew the extent of the stolen data at the time.
* Because of the nature of the termination, the breach apparently does not affect all pre-2007 customers and Scan do know all of the affected customers.
* Apparently they did inform the police of the breach, who were largely disinterested due to the nature of the stolen data (being of little value).
I hope I haven't got anything wrong in this description, but figure people have a right to know some of this information. I would also appreciate if there's anything Hexus mods can do to make the Scan-using community aware of the issue. I acknowledge that this is a difficult ask, seeing how Scan are a major sponsor of this site.
Secure?
Considerate?
Apologetic?
No!
There are currently 1 users browsing this thread. (0 members and 1 guests)