Weekly Edition
Return to the Security page
| |||||||||||||
WineHQ database compromised
Codeweavers has announced
that access to the WineHQ database has been compromised. "On the one
hand, we saw no evidence of harm to any database. We saw no evidence of any
attempt to change the database (and candidly, using the real appdb or
bugzilla is the easy way to change the database). Unfortunately, the
attackers were able to download the full login database for both the appdb
and bugzilla. This means that they have all of those emails, as well as
the passwords. The passwords are stored encrypted, but with enough effort
and depending on the quality of the password, they can be cracked."
Anybody who has reused a password stored there probably wants to make some
changes fairly soon.
(Log in to post comments)
WineHQ database compromised Posted Oct 12, 2011 0:14 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
So, who's next?
On completely unrelated note, does LWN store credit card numbers?
WineHQ database compromised Posted Oct 12, 2011 0:25 UTC (Wed) by jake (editor, #205) [Link]
> On completely unrelated note, does LWN store credit card numbers?
No we do not (thankfully) ... we transmit them to the credit card processor and are done with them at that point. For monthly subscriptions, we get back a magic cookie that can be used to charge the same account, but we don't keep credit card information.
We sleep *much* easier that way ...
jake
WineHQ database compromised Posted Oct 12, 2011 0:51 UTC (Wed) by aaron (subscriber, #282) [Link]
Tokenized card storage is a Good Thing.
BTW, as one of many sysadmins handling PCI compliance (in addition to our usual duties), can you comment on how the process worked for you?
There's a good talk coming up in Seattle this Thursday, on audit logging on Linux for compliance. Apparently, it's not as trivial as one might hope.
PCI compliance Posted Oct 12, 2011 1:01 UTC (Wed) by corbet (editor, #1) [Link] With our previous processor, the compliance process turned out to be such a silly hassle that we eventually gave up on it. They kept screaming, for example, that our version of SSH had known vulnerabilities - even though the distributor had long since patched those vulnerabilities out. All that mattered was The Checklist, which had little to do with how secure we actually were.The penalty for not being certified was a crushing $25/month; there came a point where we realized it just wasn't worth the trouble. $25/month also made it clear just how important the credit card system thought PCI compliance certification was. Now we don't let credit card numbers pass through the site at all, and things are a lot easier.
PCI compliance Posted Oct 12, 2011 9:10 UTC (Wed) by njwhite (subscriber, #51848) [Link]
> They kept screaming, for example, that our version of
> SSH had known vulnerabilities - even though the distributor had long since patched those > vulnerabilities out. All that mattered was The Checklist, which had little to do with how > secure we actually were.
Yep, that sounds about our experience, too. I ended up writing a script to scrape info of patched CVE issues from our distribution's website and emailing the PCI people a list of links to "prove" that said patches have been applied.
It's all, I think, so that the card processor can push the liability for any losses away from them.
PCI compliance Posted Oct 12, 2011 16:44 UTC (Wed) by aaron (subscriber, #282) [Link] They kept screaming, for example, that our version of SSH had known vulnerabilities - even though the distributor had long since patched those vulnerabilities out. I assume that was the ASV*, not the processor. Ours simply needed to be told the the CVEs were patched (which Debian & Ubuntu are good at doing, and more importantly, documenting.) It was a good impetus to turn off the detailed version info on our daemons. <smirk>Information leak, y'know.</smirk> Interestingly, an SSL cert. company that recently suffered security problems also happens to be an ASV.
PCI compliance Posted Oct 12, 2011 21:59 UTC (Wed) by rickmoen (subscriber, #6943) [Link]
FWIW: As someone who's gone through many, many rounds of proving PCI compliance, I can say that, yes, it's a hassle proving, each time, that your installed version of a security-sensitive package includes backported fixes not reflected in its publicly scan-able version number. I've worked out a routine where I keep handy a canned response that I can quote to answer that objection, which I haul out each testing cycle, with only minimal use of everyone's time.
Rick Moen
PCI compliance Posted Oct 13, 2011 4:05 UTC (Thu) by k8to (subscriber, #15413) [Link]
I work for a vendor who sells software that is sometimes used as part of the PCI compliance picture.
It's all too familiar to hear from customers (from auditors) that their scan-thing found a red item. Usually these red items represent bugs in the scanners, but they don't care (neither the auditor, nor the customers).
Fortunately our software doesn't have to actually pass the test software (it doesn't touch the card stream). So I point out some of the clauses of PCI compliance that say they don't have to care, and suddenly they're happy.
Sigh.
WineHQ database compromised Posted Oct 12, 2011 6:19 UTC (Wed) by Felix.Braun (subscriber, #3032) [Link]
I can certainly empathise that you feel relieved of that particular responsibility. However, I for one am not particularly sure, I trust your credit card processor more, than I trust you guys. This being said, I do trust you in selecting a reasonably sane credit card processor, so I don't worry too much.
WineHQ database compromised Posted Oct 12, 2011 17:27 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
What kind of password hashing does LWN use?
WineHQ database compromised Posted Oct 12, 2011 18:13 UTC (Wed) by jake (editor, #205) [Link]
> What kind of password hashing does LWN use?
bcrypt hashing ... see http://lwn.net/Articles/433905/ for a few more details ...
jake
Credit card numbers Posted Oct 12, 2011 0:55 UTC (Wed) by corbet (editor, #1) [Link] As Jake already said, we don't store any credit card numbers at all. It is, in fact, even better than that; our "buy now" form submits directly to the processor, so the numbers don't pass through the site at all. Among other things, that eliminates much of the PCI compliance hassle.
Storing passwords Posted Oct 12, 2011 8:59 UTC (Wed) by epa (subscriber, #39769) [Link]
No matter how many times you explain that plaintext password storage is a bad idea, there will always be some site that does it - and there is no way for users to find out whether a site hashes the passwords or not. The most obvious way is to store people's usernames and passwords, so that is what many sites will do.
What can web browsers do to make the most obvious way be a better way? Could the browser hash the passwords itself together with the site name, so while the user types the password into the login field (or 'change password' field), the site sees a hashed value which is specific to that site? Then at least if the plaintext password database is disclosed, it doesn't give any way to exploit that user's account on other sites.
PwdHash Posted Oct 12, 2011 9:21 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
"Could the browser hash the passwords itself together with the site name"
http://crypto.stanford.edu/PwdHash/ or https://www.pwdhash.com/
I use them for all my low security stuff where I "should" have separate passwords but can't be bothered to memorise them. You should definitely still practice password hygiene by not re-using the password for important stuff, since reversing the pwdhash hash (after such a site inevitably lets the plaintext passwords out the door) is merely difficult, not close to impossible for most people's passwords.
I keep expecting Firefox to just build this feature into the browser, but it seems it isn't happening.
Where you have any site-design influence you should try to avoid passwords anyway. OpenID, or even one of the nasty proprietary "connect" solutions are better from a security point of view by removing the password database from the unrelated application software.
PwdHash Posted Oct 12, 2011 9:41 UTC (Wed) by bjartur (guest, #67801) [Link] But note that this can't be done by default, as it would break the killer-feature of HTTP and cookie authentication: allowing you to walk to any public terminal and start reading lwn. Terribly insecure, considering how easy it is to log keypresses on public terminals, but convenient. There was a discussion on the WHATWG ML about allowing sites to request client-side hashing of passwords with a standardized on hashing algorithm, or in other words, to allow sites to tell your friend's user agent how to hash your password. Maybe you'd lake to participate in the discussion?Disclaimer: I unsubscribed from the list minutes ago.
PwdHash Posted Oct 12, 2011 12:13 UTC (Wed) by epa (subscriber, #39769) [Link] But note that this can't be done by default, as it would break the killer-feature of HTTP and cookie authentication: allowing you to walk to any public terminal and start reading lwn.Why not? The hash is based on the password entered and the domain name of the site - no information specific to the local machine is used. So it would give the same hash no matter what computer you sat down at.
PwdHash Posted Oct 12, 2011 12:46 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
Indeed. I have actually done this, using pwdhash.com to generate the necessary input since I lacked the browser extension that does it for me at home. You can also get software to run on your smart phone that spits out the hashed password, and it doesn't need to very smart, mobile Java that can do mOTP or currency conversion is enough CPU power and UI capability for this problem.
There are lots of ways this stuff could be smarter or better, but PwdHash does seem like a pretty good stop gap for the foreseeable future.
PwdHash Posted Oct 13, 2011 4:58 UTC (Thu) by k8to (subscriber, #15413) [Link]
Note that in this case, it was a database loophole compromise, so the stored values were acquired, not the incoming authentication stream.
The stored values are hashes, so the attacker got the hashes. WineHQ is just being realistic that crack will recover many of them soon enough, and is warning users to alter their passwords elsewhere.
I am very happy that I keep the passwords I use for each site in an easily reviewed form, so I could quickly determine that there is no overlap.
Realistically though, I would rather not have ever had a password or account at all for their bugzilla. I had to file a bug, and I'd have rather just emailed it in, possibly with a mailback to verify validity. The fact that bugzilla is broken for this common workflow is a bug I filed against bugzilla.
Storing passwords Posted Oct 12, 2011 9:25 UTC (Wed) by mordae (subscriber, #54701) [Link]
This might actually work. Just have site return an unique ID in HTTP header or meta tag and use that ID, hashed master string user enters plus the password user types and send that with a special HTTP header indicating what you've done.
If this gets implemented properly and browsers inform user that they are sending over raw password, sites might actually implement that.
Storing passwords Posted Oct 12, 2011 9:43 UTC (Wed) by bjartur (guest, #67801) [Link]
You're essentially describing HTTP Digest authentication w/o the randomized client nonce.
That has actually been implemented in most major HTTP clients. Does lwn support it?
Storing passwords Posted Oct 12, 2011 12:08 UTC (Wed) by mordae (subscriber, #54701) [Link]
Ah, there is also the "registration password is hashed in the same way" part missing in my post. Once we've sent password to the server unencrypted, it's not sane to assume it have been stored securely even if we authenticate through digests.
Storing passwords Posted Oct 12, 2011 20:18 UTC (Wed) by HenrikH (guest, #31152) [Link]
If I'm not mistaken HTTP digest requires the site to store the passwords as plain text since it has to perform calculations with it, so I hope that lwn doesn't support it :)
Storing passwords Posted Oct 13, 2011 15:59 UTC (Thu) by beect (guest, #71486) [Link]
Sites using HTTP Digest can store MD5(username : realm : password). Not much protection, but better than plaintext.
Storing passwords Posted Oct 12, 2011 12:14 UTC (Wed) by epa (subscriber, #39769) [Link] Just have site return an unique ID in HTTP header or meta tagI was hoping for something that browsers could implement immediately without any co-operation from sites, since it's clear that a large number of websites won't put any effort into improving password security.
Storing passwords Posted Oct 12, 2011 12:56 UTC (Wed) by iq-0 (subscriber, #36655) [Link]
Well the idea of PwdHash matches almost perfectly with how eg. Firefox stores you credentials in the password manager. So it could do this 100% client side for all cases where you would normally get the "do you want to remember this password?" popup (and no this doesn't mean you have to use the password manager itself, you'd just use the same username/password/site recognition heuristics as the password manager would use).
But a more tightly coupled approach with you password manager can improve a bit on this scheme (probably only really sensible when using firefox sync if you work on more than 1 computer) by adding another piece of random data that is stored in you password manager (still regardless of whether it would include you password itself).
Also they could improve on it by using their crypto backend especially when one has a hardware cryptoki. Most browsers already support this for logging in using client certificates. This could be used to sign the username/site pair with your key and use that as a password. Effectively limiting the use to 1 site. Though you'd still want to add state to the browser, otherwise you'd be unable to generate a distinct password for a site once it has been restored after hack and the attacker could still access the site as you (or you'd have to create a new username, but that would be a stupid restriction). That state by the way doesn't have to be secure, you could just put it on some publicly readable site (eg. in your facebook profile description, than it would at least be put to good use :-D)
Storing passwords Posted Oct 12, 2011 14:40 UTC (Wed) by endecotp (guest, #36428) [Link]
> there is no way for users to find out whether a site hashes
> the passwords or not.
A good guide is
- Has a "email password reminder" button => passwords not hashed
(This isn't perfect, but I bet it's very close.)
Storing passwords Posted Oct 12, 2011 17:31 UTC (Wed) by quotemstr (subscriber, #45331) [Link] Too often, the "passwords hashed" case boils down to a single, unsalted iteration of MD5. Given the availability of large rainbow tables, this password storage approach is scarcely better than plain text. While hashing passwords is a good first step, the naive approach is insufficient. It's important to do it right.
phpass Posted Oct 13, 2011 20:04 UTC (Thu) by Cato (subscriber, #7643) [Link]
For those with PHP web applications, phpass is an excellent library that's easy to integrate: http://www.openwall.com/phpass/ - it includes password stretching and supports bcrypt, but also works with old versions of PHP that only support MD5, by iterating it thousands of times to increase the work required by crackers.
Really the best solution is two-factor authentication - supplement weak and easily stolen passwords with something you have (like a mobile phone or a landline).
Storing passwords Posted Oct 15, 2011 21:26 UTC (Sat) by tialaramex (subscriber, #21167) [Link]
In this case it seems they were using Bugzilla, which somewhere along the line went from Perl's clone of old school crypt() to a hand-rolled (inevitably) salted SHA256 hash.
So, not completely awful, but pretty bad. Not once during the long thread of comments on Bugzilla does anybody think that maybe they should see if this critical security work has already been done, properly, by someone who actually knows what they're doing... Wheel? What's that, this is my rotating movement device.
|
|||||||||||||