On Feb 5, 2014 8:21 AM, MZMcBride z...@mzmcbride.com 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
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
On Wed, Feb 5, 2014 at 2:58 AM, Tyler Romeo tylerro...@gmail.com 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
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 this
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. Of
course,
On Wed, Feb 5, 2014 at 4:12 AM, Nathan Larson nathanlarson3...@gmail.comwrote:
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
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
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 strings
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.
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
On Wed, Feb 5, 2014 at 1:03 PM, Brion Vibber bvib...@wikimedia.org 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
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
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
On Wed, Feb 5, 2014 at 3:08 PM, Zachary Harris zacharyhar...@hotmail.comwrote:
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
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 that
On Tue, Feb 4, 2014 at 11:59 PM, Martijn Hoekstra martijnhoeks...@gmail.com
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
Hi.
Tyler Romeo wrote:
On Wed, Feb 5, 2014 at 2:20 AM, MZMcBride z...@mzmcbride.com 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
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
Hi.
https://www.mediawiki.org/wiki/Gerrit/Reports stopped updating for a few
days due to https://bugzilla.wikimedia.org/60940 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
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
20 matches
Mail list logo
