It is time to think what is wrong and what should be improved,
codeweavers needs to implement HTTPS (at least with a self signed
cert, to save money, so that it is up to the user to verify the cert)
and DNSSEC should also be implemented like Debian, Mozilla and tor
websites.
--
Thanks
WineHQ database compromise
-
Paul Nakada
WineHQ database compromise
i can't believe you sent emails with passwords in cleartext. thank you so much.
-p
Paul Nakada
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-us ... hment.html>
-p
Paul Nakada
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-us ... hment.html>
-
Frédéric Delanoy
WineHQ database compromise
On Wed, Oct 12, 2011 at 06:58, Paul Nakada <[email protected]> wrote:
pwd, there's not much one could do.
But I'm not sure the overhead that implies is reasonable for a public
bugzilla (there's not much money to gain, aside from some kind of spam
maybe)
Maybe the mail should mention to directly change that pwd (or provide
a one-time pwd you need to change on first login), but then again it's
plain http, so that doesn't help much.
Frédéric
Well to be fair, unless you use some encryption like gpg to send thei can't believe you sent emails with passwords in cleartext. thank you so much.
Paul Nakada
pwd, there's not much one could do.
But I'm not sure the overhead that implies is reasonable for a public
bugzilla (there's not much money to gain, aside from some kind of spam
maybe)
Maybe the mail should mention to directly change that pwd (or provide
a one-time pwd you need to change on first login), but then again it's
plain http, so that doesn't help much.
Frédéric
-
Federico Leva (Nemo)
WineHQ database compromise
I've just used http://wejn.org/stuff/moz-export.html to discover itThat's the problem. I don't know what my old password was, so I don't
know what other sites, if any, I've used it for.
(works on GNU/Linux; I'm not an expert but from the source doesn't seem
to forward your passwords to anyone).
Nemo
-
Martin Gregorie
WineHQ database compromise
On Wed, 2011-10-12 at 10:27 +0200, Frédéric Delanoy wrote:
Note that that message contains both the 'user name' AND the plaintext
password, but as others have said, this is unavoidable. Immediately on
receipt of the message, the user should:
- login using that password
- change the password to one of his own choice
- logout
BTW, it would most useful to know more about the type of password that
can be used, in particular:
- maximum and minimum lengths
- what characters are acceptable. A password should be case sensitive
and contain any printable character. Systems that are case agnostic
and accept only the characters a-z0-9 are simply not good enough.
Systems that accept a longer passphrase are good on two counts: a
phrase is often easier to remember and its length makes it harder
to crack.
- if a dictionary is used to ban easily guessable passwords
- if passwords can be re-used - ideally not.
Martin
Anybody with half a brain will have done that anyway.Maybe the mail should mention to directly change that pwd (or provide
a one-time pwd you need to change on first login), but then again it's
plain http, so that doesn't help much.
Note that that message contains both the 'user name' AND the plaintext
password, but as others have said, this is unavoidable. Immediately on
receipt of the message, the user should:
- login using that password
- change the password to one of his own choice
- logout
BTW, it would most useful to know more about the type of password that
can be used, in particular:
- maximum and minimum lengths
- what characters are acceptable. A password should be case sensitive
and contain any printable character. Systems that are case agnostic
and accept only the characters a-z0-9 are simply not good enough.
Systems that accept a longer passphrase are good on two counts: a
phrase is often easier to remember and its length makes it harder
to crack.
- if a dictionary is used to ban easily guessable passwords
- if passwords can be re-used - ideally not.
Martin
WineHQ database compromise
Hi Vasily,
On 10/11/2011 04:30 PM, Vasiliy Faronov wrote:
The bugs database is bugzilla; we simply use bugzilla standard encryption.
The current form of that is a fairly complex salted sha 256 string. However,
that started in bugzilla version 4, which was released only this year.
For passwords encrypted in bugzilla prior to that, a simple crypt() was used.
I haven't yet looked at the bugzilla code to determine if it was salted or not,
or exactly how that crypt() was called. The encrypted text is roughly the same
length as a 64 bit DES encryption.
The appdb uses the sha1() mysql function which is a straight forward sha1sum.
I have yet to find a password that yields to a very simple crack attempt
(using john, and hashcrack.com), but I have not tried in any systematic way.
I won't claim to be a cryptography expert, as I'm not. My back of the envelope
analysis is that if you have a moderately complex password, you will likely
be safe from any straight forward attempts to crack your password. You may still
be at risk to an extended brute force attack. But here my ignorance kicks in;
I don't know where the curve of password length + complexity matches the curve
of 'time required to brute force an sha1'.
On the other hand, if you use a password that is a dictionary word,
or only a trivial distance from a dictionary word, then I would suspect
your password would fall to a fairly basic dictionary attack.
Cheers,
Jeremy
On 10/11/2011 04:30 PM, Vasiliy Faronov wrote:
I'll give you a short answer; if I get more details, I'll supply the long one.Hi Jeremy,
Could you please reveal details on how the passwords were "encrypted"?
Which hash function, were they salted, was the salt compromised.
This would help the users evaluate just how much is "enough effort"
to crack the passwords.
The bugs database is bugzilla; we simply use bugzilla standard encryption.
The current form of that is a fairly complex salted sha 256 string. However,
that started in bugzilla version 4, which was released only this year.
For passwords encrypted in bugzilla prior to that, a simple crypt() was used.
I haven't yet looked at the bugzilla code to determine if it was salted or not,
or exactly how that crypt() was called. The encrypted text is roughly the same
length as a 64 bit DES encryption.
The appdb uses the sha1() mysql function which is a straight forward sha1sum.
I have yet to find a password that yields to a very simple crack attempt
(using john, and hashcrack.com), but I have not tried in any systematic way.
I won't claim to be a cryptography expert, as I'm not. My back of the envelope
analysis is that if you have a moderately complex password, you will likely
be safe from any straight forward attempts to crack your password. You may still
be at risk to an extended brute force attack. But here my ignorance kicks in;
I don't know where the curve of password length + complexity matches the curve
of 'time required to brute force an sha1'.
On the other hand, if you use a password that is a dictionary word,
or only a trivial distance from a dictionary word, then I would suspect
your password would fall to a fairly basic dictionary attack.
Cheers,
Jeremy
Re: WineHQ database compromise
Regardless of this incident, anyone using such passwords needs to change them anyways, so maybe this can work as a wake up call.jwhite wrote: On the other hand, if you use a password that is a dictionary word,
or only a trivial distance from a dictionary word, then I would suspect
your password would fall to a fairly basic dictionary attack.
Someone recently broke one of my gmail accounts somehow that was using 7 characters letters and numbers, no words... luckily I don't keep anyone in my online address book except my other accounts, so I just got spammed from my own account and Google disabled my account temporarily due to suspicious activity. Seems like the days for 15 character complex password requirements are getting here soon.
-
jjmckenzie
- Moderator
- Posts: 1153
- Joined: Wed Apr 27, 2011 11:01 pm
WineHQ database compromise
On Wed, Oct 12, 2011 at 7:30 AM, doh123 <[email protected]> wrote:
has been that way for two years now. I highly suggest using a
password of at least 256 bits or higher.
However, if someone were to break into Wine Bugzilla, how hard would
it be to clean up the mess? I don't know, but I would suggest a close
watch on current and new bug entries until this has been completely
cleaned up and all accounts locked out or have a password changes as
there are accounts that have not been used for a long time.
I also suggest a 60 day lockout. Any account not used for 60 days
gets locked out with an unlock with security question unlock....
James
One of my accounts REQUIRES a 15 letter or longer password. And itjwhite wrote:Regardless of this incident, anyone using such passwords needs to change them anyways, so maybe this can work as a wake up call.On the other hand, if you use a password that is a dictionary word,
or only a trivial distance from a dictionary word, then I would suspect
your password would fall to a fairly basic dictionary attack.
Someone recently broke one of my gmail accounts somehow that was using 7 characters letters and numbers, no words... luckily I don't keep anyone in my online address book except my other accounts, so I just got spammed from my own account and Google disabled my account temporarily due to suspicious activity. Seems like the days for 15 character complex password requirements are getting here soon.
has been that way for two years now. I highly suggest using a
password of at least 256 bits or higher.
However, if someone were to break into Wine Bugzilla, how hard would
it be to clean up the mess? I don't know, but I would suggest a close
watch on current and new bug entries until this has been completely
cleaned up and all accounts locked out or have a password changes as
there are accounts that have not been used for a long time.
I also suggest a 60 day lockout. Any account not used for 60 days
gets locked out with an unlock with security question unlock....
James
-
Josh Juran
WineHQ database compromise
On Oct 12, 2011, at 5:58 AM, Jeremy White wrote:
Josh
I'm not a cryptographer either, but note that SHA-1 is used by Git and others for its speed. For hashing passwords, this is a bug, not a feature -- checking passwords should be slow rather than quick. One hash function designed for passwords is bcrypt().The current form of that is a fairly complex salted sha 256 string. However,
that started in bugzilla version 4, which was released only this year.
For passwords encrypted in bugzilla prior to that, a simple crypt() was used.
I haven't yet looked at the bugzilla code to determine if it was salted or not,
or exactly how that crypt() was called. The encrypted text is roughly the same
length as a 64 bit DES encryption.
The appdb uses the sha1() mysql function which is a straight forward sha1sum.
I won't claim to be a cryptography expert, as I'm not. My back of the envelope
analysis is that if you have a moderately complex password, you will likely
be safe from any straight forward attempts to crack your password. You may still
be at risk to an extended brute force attack. But here my ignorance kicks in;
I don't know where the curve of password length + complexity matches the curve
of 'time required to brute force an sha1'.
Josh
-
GOUJON Alexandre
WineHQ database compromise
On 10/11/2011 09:13 PM, Jeremy White wrote:
So, now or later, your system will be compromised.
The only thing you have to do is to be prepared to face an incident and
of course secure your systems to slow the attacker(s) down.
The bugzilla case does not really worry me because it's only bugs.
But as CEO, you have to protect your company and your customers.
I'm of course a simple "user" of wine and I have absolutely not the
right to tell you what to do.
But something was open, broken or whatever .. and now you have to spend
time and energy to try to repair the breach.
Just don't let it happen again.
There are lots of methods to analyse risk.
Depending on what level of security you want, it will cost more or less.
Just think about it.
Anyway, thanks for the quick reply, communication is really important in
this situation.
"Nothing Is Invulnerable"I am sad to say that there was a compromise of the WineHQ database system.
So, now or later, your system will be compromised.
The only thing you have to do is to be prepared to face an incident and
of course secure your systems to slow the attacker(s) down.
The bugzilla case does not really worry me because it's only bugs.
But as CEO, you have to protect your company and your customers.
I'm of course a simple "user" of wine and I have absolutely not the
right to tell you what to do.
But something was open, broken or whatever .. and now you have to spend
time and energy to try to repair the breach.
Just don't let it happen again.
There are lots of methods to analyse risk.
Depending on what level of security you want, it will cost more or less.
Just think about it.
Anyway, thanks for the quick reply, communication is really important in
this situation.
WineHQ database compromise
Hey Josh,
You can spend a long time trying to decide on a better strategy, and
sha1 is no longer considered a particularly good strategy.
I will point out that the appdb is a completely volunteer effort, and I
think it needs volunteers badly. So, patches are more than welcome
<evil grin>.
Cheers,
Jeremy
Yes, absolutely. There is a lot of thought that has gone into this.I'm not a cryptographer either, but note that SHA-1 is used by Git and others for its speed. For hashing passwords, this is a bug, not a feature -- checking passwords should be slow rather than quick. One hash function designed for passwords is bcrypt().
You can spend a long time trying to decide on a better strategy, and
sha1 is no longer considered a particularly good strategy.
I will point out that the appdb is a completely volunteer effort, and I
think it needs volunteers badly. So, patches are more than welcome
<evil grin>.
Cheers,
Jeremy
-
Maarten Lankhorst
WineHQ database compromise
Hey,
On 10/12/2011 12:46 AM, Josh Juran wrote:
Or better yet, force automatic redirect to https, with Strict-Transport-Security:
https://hacks.mozilla.org/2010/08/firef ... rce-https/
If winehq can't get more ips for every subdomain (ssl sucks), would the solution be moving it to https://winehq.org/{bugs,appdb,test,source} ?
Cheers,
Maarten
On 10/12/2011 12:46 AM, Josh Juran wrote:
If I go to any https://*.winehq.org website I get the certificate for test.winehq.org , otherwise you could use the firefox https anywhere to force https on.On Oct 11, 2011, at 3:37 PM, Conan Kudo (ニール・ゴンパ) wrote:
To clarify, your browser sends your password to bugzilla in cleartext, since HTTPS isn't an option.On Tue, Oct 11, 2011 at 3:39 PM, Josh Juran <[email protected]> wrote:
Wait, what? Bugzilla sends passwords in cleartext? That isn't very smart... Is there no way to replace this with some sort of client based hashing or something?Since bugzilla passwords were sent in cleartext anyway, I sincerely hope none of them were otherwise valuable. (Remember FireSheep?)
Firesheep was a lesson that even once passwords are secure, session credentials are still vulnerable to sniffing. Some sites went to HTTPS-only sessions after that.
Or better yet, force automatic redirect to https, with Strict-Transport-Security:
https://hacks.mozilla.org/2010/08/firef ... rce-https/
If winehq can't get more ips for every subdomain (ssl sucks), would the solution be moving it to https://winehq.org/{bugs,appdb,test,source} ?
Cheers,
Maarten
-
msmeissn
WineHQ database compromise
On Thu, Oct 13, 2011 at 10:23:58AM +0200, Maarten Lankhorst wrote:
Ciao, Marcus
Or a wildcard SSL cert for *.winehq.org.Hey,
On 10/12/2011 12:46 AM, Josh Juran wrote:If I go to any https://*.winehq.org website I get the certificate for test.winehq.org , otherwise you could use the firefox https anywhere to force https on.On Oct 11, 2011, at 3:37 PM, Conan Kudo (ニール・ゴンパ) wrote:
To clarify, your browser sends your password to bugzilla in cleartext, since HTTPS isn't an option.On Tue, Oct 11, 2011 at 3:39 PM, Josh Juran <[email protected]> wrote:
Wait, what? Bugzilla sends passwords in cleartext? That isn't very smart... Is there no way to replace this with some sort of client based hashing or something?
Firesheep was a lesson that even once passwords are secure, session credentials are still vulnerable to sniffing. Some sites went to HTTPS-only sessions after that.
Or better yet, force automatic redirect to https, with Strict-Transport-Security:
https://hacks.mozilla.org/2010/08/firef ... rce-https/
If winehq can't get more ips for every subdomain (ssl sucks), would the solution be moving it to https://winehq.org/{bugs,appdb,test,source} ?
Ciao, Marcus
