Re: [Wikitech-l] Password Hash

2014-02-05 Thread Daniel Friesen
Strictly speaking it would be best to implement PBKDF2 to accept any hash algorithm it's configured with – like I did in my password-hashing branch – rather than using just whirlpool. I thought I even used whirlpool myself as the default in my branch, but it looks like I actually played it safe an

[Wikitech-l] [Bug 60940] Gerrit throwing internal server error with "status:closed" queries

2014-02-05 Thread MZMcBride
Hi. https://www.mediawiki.org/wiki/Gerrit/Reports stopped updating for a few days due to as far as I can tell. For now I've just disabled checking changes that have a status of "closed". The reports should resume updating daily, but some of the reports will

Re: [Wikitech-l] Password Hash

2014-02-05 Thread C. Scott Ananian
Password hashing algorithms are not the same as general hash algorithms. I would prefer we didn't use whirlpool; it is "recommended by NESSIE and ISO" as a hash function, but as a password hash. CWE916 recommends "bcrypt, scrypt, and PBKDF2" specifically for password hashing. To be clear, I have

Re: [Wikitech-l] Let's improve our password policy

2014-02-05 Thread MZMcBride
Hi. Tyler Romeo wrote: >On Wed, Feb 5, 2014 at 2:20 AM, MZMcBride wrote: >> Ultimately, account security is a user's prerogative. [...] Banks and >>even e-mail providers have reason to implement stricter authentication >>requirements. > >This is conflicting logic. If it is the user's job to enfor

Re: [Wikitech-l] Let's improve our password policy

2014-02-05 Thread Steven Walling
On Tue, Feb 4, 2014 at 11:59 PM, Martijn Hoekstra wrote: > I think Steven meant upping the requirements for new accounts only. In that > way nothing gets broken immediately. I'm still not absolutely convinced > this is more useful than a hindrance if we clearly inform the user about > password st

Re: [Wikitech-l] Let's improve our password policy

2014-02-05 Thread Steven Walling
On Tue, Feb 4, 2014 at 11:20 PM, MZMcBride wrote: > General consensus (on this mailing list and at the RFC) seems to be that > we can certainly encourage stronger passwords, but we should not require > stronger passwords for standard accounts. Accounts with escalated > privileges (admin, checkuse

Re: [Wikitech-l] Password Hash

2014-02-05 Thread Marc A. Pelletier
On 02/05/2014 09:34 PM, Tim Starling wrote: > Maybe Chris's phrasing misled you: I didn't invent the Whirlpool > algorithm And so it did; something a quick google would have revealed. In my defense, "The Whirlpool algorithm by Tim" was pretty convincing attribution. :-) I'd need to read up on th

Re: [Wikitech-l] Password Hash

2014-02-05 Thread Tim Starling
On 06/02/14 08:17, Marc A. Pelletier wrote: > On 02/05/2014 03:53 PM, Chris Steipp wrote: >> The Whirlpool algorithm by Tim would force password cracking software to do >> a custom implementation for our hashes. > > No judgment is passed on Tim, but rule number one of crypto is never try > to roll

Re: [Wikitech-l] Password Hash

2014-02-05 Thread Chris Steipp
On Wed, Feb 5, 2014 at 3:08 PM, Zachary Harris wrote: > tl;dr PBKDF2 and bcrypt are both perfectly acceptable for security. > > > PBKDF2 and bcrypt, as well as scrypt, are all well regarded by current > infosec industry standards (with "current" being a key word). " While > there is active debate

Re: [Wikitech-l] Password Hash

2014-02-05 Thread Zachary Harris
tl;dr PBKDF2 and bcrypt are both perfectly acceptable for security. PBKDF2 and bcrypt, as well as scrypt, are all well regarded by current infosec industry standards (with "current" being a key word). " While there is active debate about which of these is the most effective, they are all stronger

Re: [Wikitech-l] IRC meeting for RFC review

2014-02-05 Thread Sumana Harihareswara
Reminder: today's meeting https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-05is happening now in #wikimedia-meetbot. Sorry for the delayed announcement. Sumana Harihareswara Engineering Community Manager Wikimedia Foundation On Sun, Sep 22, 2013 at 11:26 PM, Tim Starling w

Re: [Wikitech-l] Password Hash

2014-02-05 Thread Chris Steipp
On Wed, Feb 5, 2014 at 1:03 PM, Brion Vibber wrote: > Offhand I'd say "use bcrypt", but from http://us3.php.net/password_hash -- > > "*Caution* > > Using the *PASSWORD_BCRYPT* for the *algo* parameter, will result in the > *password* parameter being truncated to a maximum length of 72 characters.

Re: [Wikitech-l] Password Hash

2014-02-05 Thread Marc A. Pelletier
On 02/05/2014 03:53 PM, Chris Steipp wrote: > The Whirlpool algorithm by Tim would force password cracking software to do > a custom implementation for our hashes. No judgment is passed on Tim, but rule number one of crypto is never try to roll your own unless you happen to have years and years of

Re: [Wikitech-l] Password Hash

2014-02-05 Thread Jeroen De Dauw
Hey, Is the 72-byte truncation a general bcrypt problem or specific to > password_hash()? Any concerns or a non-issue? Note that some non-Latin > strings can only fit 24 chars in 72 bytes of UTF-8. Long enough for most > passwords, but some people like passphrases. :) > I have a 100 char password

Re: [Wikitech-l] Password Hash

2014-02-05 Thread Brion Vibber
Offhand I'd say "use bcrypt", but from http://us3.php.net/password_hash -- "*Caution* Using the *PASSWORD_BCRYPT* for the *algo* parameter, will result in the *password* parameter being truncated to a maximum length of 72 characters. This is only a concern if are using the same salt to hash strin

[Wikitech-l] Password Hash

2014-02-05 Thread Chris Steipp
Hi all, I wanted to bikeshed just a little bit, to make sure there is some consensus. tl;dr We're upgrading the password hash used to store passwords to make offline cracking more difficult. In doing that, we need to set one of the options as default. Speak up if you have strong feelings about one

Re: [Wikitech-l] Let's improve our password policy

2014-02-05 Thread Tyler Romeo
On Wed, Feb 5, 2014 at 4:12 AM, Nathan Larson wrote: > What if all of the email addresses that a user has ever used were to be > stored permanently? Then in the event of an account hijacking, he could say > to WMF, "As your data will confirm, the original email address for user Foo > was f...@exam

Re: [Wikitech-l] Let's improve our password policy

2014-02-05 Thread Derric Atzrott
>> For example, MZMcBride, what if your password is "wiki", and somebody >> compromises your account, and changes your password and email. You don't >> have a committed identity, so your account is now unrecoverable. You now >> have to sign up for Wikipedia again, using the username "MZMcBride2". O

Re: [Wikitech-l] Let's improve our password policy

2014-02-05 Thread Brian Wolff
> > I think Steven meant upping the requirements for new accounts only. In that > way nothing gets broken immediately. I'm still not absolutely convinced > this is more useful than a hindrance if we clearly inform the user about > password strength when they set them (see my earlier post about "thi

Re: [Wikitech-l] Let's improve our password policy

2014-02-05 Thread Nathan Larson
On Wed, Feb 5, 2014 at 2:58 AM, Tyler Romeo wrote: > For example, MZMcBride, what if your password is "wiki", and somebody > compromises your account, and changes your password and email. You don't > have a committed identity, so your account is now unrecoverable. You now > have to sign up for Wi

Re: [Wikitech-l] Let's improve our password policy

2014-02-05 Thread Vito
Let's say they are nearly valueless for most of attackers. Generally speaking I think we should strongly encourage security without imposing it. A "strenght meter", some email reminder and a minimum of six chars for new passwords would be, imho, non-invasive good measures. Vito Inviato con A

Re: [Wikitech-l] Let's improve our password policy

2014-02-05 Thread Martijn Hoekstra
On Feb 5, 2014 8:21 AM, "MZMcBride" wrote: > > Steven Walling wrote: > >I fully agree, and this is why the RFC is very clear that the *only > >immediate change proposed* is an increase in required minimum length from > >one character to six. It does not suggest that we require more complex > >char