https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
Helder changed:
What|Removed |Added
URL||https://de.wikipedia.org/wi
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
Antoine "hashar" Musso changed:
What|Removed |Added
CC|has...@free.fr |
--
You are receiving this m
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #33 from MZMcBride ---
(In reply to comment #30)
> And MZMcBride... your talking about user convenience. But
> convenience<->security is always a matter of the right balance. And frankly.
> The difference in convenience between a us
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #32 from Matthew Flaschen ---
I've started an RFC. I based it on Chris's idea, and tried to keep it simple:
https://www.mediawiki.org/wiki/Requests_for_comment/Password_requirements
I have also posted this to wikitech-l.
By the
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
Nemo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #30 from Daniel Friesen ---
(In reply to comment #25)
> Daniel and Tyler were working on a password backend rework last summer, that
> I'm really sorry I missed pushing internally. Both, iirc, prompted for a
> password change on log
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #29 from Antoine "hashar" Musso ---
I do not think you should continue arguing on this bug report :-] Maybe you
want to open a request for comment at
http://www.mediawiki.org/wiki/Requests_for_comment
It could list all possible ca
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #28 from Matthew Flaschen ---
(In reply to comment #25)
> One proposal I'll make is to remove the check that the password meets the
> minimum length on login, and enforce it on account creation and password
> change. That (I think,
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #27 from MZMcBride ---
(In reply to comment #25)
> * With our rate limits what they are, you can actually brute force
> single-character passwords (15-30 mins each, before you optimize for user
> bias in choosing the single digit) f
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
MZMcBride changed:
What|Removed |Added
Summary|increase|Increase
|$wgMinimalPass
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #25 from Chris Steipp ---
I'll add some non-admin attack scenarios:
* With our rate limits what they are, you can actually brute force
single-character passwords (15-30 mins each, before you optimize for user bias
in choosing the s
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #24 from Dario Taraborelli ---
> Okay, keep going. They get into someone's account, and then what? I don't see
the attack scenario.
Obtain credentials for an admin account, edit a few lines of JS in the MW
namespace, take down wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
Nemo changed:
What|Removed |Added
Keywords||shellpolicy
Status|NEW
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #22 from MZMcBride ---
(In reply to comment #21)
> They impersonate them, then edit (and maybe email) under their name.
>
> Maybe you think that's irrelevant for regular editors. I think it's still a
> serious problem, just not as
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #21 from Matthew Flaschen ---
> Okay, keep going. They get into someone's account, and then what? I don't see
> the attack scenario.
They impersonate them, then edit (and maybe email) under their name.
Maybe you think that's irrel
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #20 from MZMcBride ---
(In reply to comment #19)
> (In reply to comment #17)
>> (In reply to comment #15)
>>> However, password brute-forcing can be used against anyone, even those who
>>> always use HTTPS.
>>
>> To what end?
>
>
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #19 from Matthew Flaschen ---
(In reply to comment #17)
> (In reply to comment #15)
> > However, password brute-forcing can be used against anyone, even those who
> > always use HTTPS.
>
> To what end?
To get into their account, t
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #18 from p858snake ---
Could we not program it to prompt the user to change their password if its
"weak"/"under the X character count"? which would seem to solve most of the
issues/arguments presented here about locking people out.
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #17 from MZMcBride ---
(In reply to comment #15)
> However, password brute-forcing can be used against anyone, even those who
> always use HTTPS.
To what end?
--
You are receiving this mail because:
You are the assignee for the b
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
Daniel Friesen changed:
What|Removed |Added
CC||mediawiki-bugs@nadir-seen-f
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #15 from Matthew Flaschen ---
"Of course, with logins still not required to use HTTPS, a lot of these
security
measures look rather silly."
There are different attack scenarios, all of which should be dealt with.
HTTPS is certainl
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #14 from Matthew Flaschen ---
> Why a mistake? You know, before the minimum password length was 1, it was 0.
I know that. I haven't heard a good explanation of why it was bumped only to
1, rather than something more reasonable.
I
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
Matthew Flaschen changed:
What|Removed |Added
See Also||https://bugzilla.wikimedia.
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
Ori Livneh changed:
What|Removed |Added
CC||o...@wikimedia.org
--- Comment #13 from O
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #12 from MZMcBride ---
(In reply to comment #11)
> I don't think we should guarantee that users with very weak passwords (say
> under 6 characters, but we could draw the line elsewhere) should be able to
> log in forever (without ch
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
Dario Taraborelli changed:
What|Removed |Added
CC|dar...@wikkawiki.org|
--
You are receiving this mail b
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #11 from Matthew Flaschen ---
I don't think we should guarantee that users with very weak passwords (say
under 6 characters, but we could draw the line elsewhere) should be able to log
in forever (without changing or resetting the p
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
MZMcBride changed:
What|Removed |Added
CC||b...@mzmcbride.com
--
You are receiving t
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
Matthew Flaschen changed:
What|Removed |Added
CC||dtarabore...@wikimedia.org
--
You
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
Matthew Flaschen changed:
What|Removed |Added
CC||dar...@wikkawiki.org,
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
Mark A. Hershberger changed:
What|Removed |Added
Priority|High|Low
--- Comment #10 from Mark A.
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #9 from Platonides 2010-11-16 15:54:59 UTC
---
That they can't login with a password too short was done on purpose in r9312
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving th
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #8 from Aryeh Gregor 2010-11-16
00:20:15 UTC ---
(In reply to comment #7)
> (BTW, I tried running a query as root on the toolserver to see how many users
> had ' ' as a password, but it's taking an awfully long time. It's possible
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #7 from Aryeh Gregor 2010-11-15
22:31:10 UTC ---
As I've remarked elsewhere repeatedly and at length, I don't think unprivileged
users should have any password strength requirements. It hurts them and no one
else if their account
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #6 from ✓ 2010-11-15 19:11:26 UTC ---
(In reply to comment #3)
> Password are encrypted with md5 and salted.
I thought as much. Bruteforcing is neither a solution, it might be possible for
1-char passwords, but 2 or 3 are also not
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #5 from Platonides 2010-11-15 18:44:13 UTC
---
Another option is to allow login once with a one character password, forcing
them to change it.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- Y
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
--- Comment #4 from Max Semenik 2010-11-15 18:42:20 UTC
---
Actually, bruteforcing 1-char password is easy, despite even salt.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail b
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
Ashar Voultoiz changed:
What|Removed |Added
CC||has...@free.fr
--- Comment #3 from As
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
✓ changed:
What|Removed |Added
CC||andbe...@web.de
--- Comment #2 from ✓ 2010-11-15
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
Platonides changed:
What|Removed |Added
CC||platoni...@gmail.com,
|
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925
Frank Selton changed:
What|Removed |Added
Priority|Normal |High
CC|
41 matches
Mail list logo
