Hi everyone,
For some time now we've had two Requests for Comment floating around related to passwords, neither of them making much progress.
One is the older "password strength" RFC which proposed creating a module to tell users about the strength of their passwords. The second, "Password requirements", had some discussion but wasn't reaching consensus and implementation.
After proposing it about a month ago, I've merged these two RFCs and refactored them in to https://www.mediawiki.org/wiki/Requests_for_comment/Passwords, partially based on feedback from Chris Steipp.
Please comment. I've tried to sharpen the proposals down in to one thing we can do _right now_ which will do the most good for the most users. However, there are several other viable ideas which merit discussion and example implementations.
Thanks!
Steven
hi steven,
thanks for this proposal. what i trap into consistently since years is not beeing logged in, when i want to. i'd really appreaciate if this is shown clearly, on all wiki's. i never can remember which ones indicate it and which ones not. mediawiki.org indicates it, btw ... and i was trying to comment there not logged in :)
for the password policy: display a strength indicator is great. anything more? i would say just leave it to the user.
rupert.
On Fri, Jan 24, 2014 at 8:50 PM, Steven Walling steven.walling@gmail.comwrote:
Hi everyone,
For some time now we've had two Requests for Comment floating around related to passwords, neither of them making much progress.
One is the older "password strength" RFC which proposed creating a module to tell users about the strength of their passwords. The second, "Password requirements", had some discussion but wasn't reaching consensus and implementation.
After proposing it about a month ago, I've merged these two RFCs and refactored them in to https://www.mediawiki.org/wiki/Requests_for_comment/Passwords, partially based on feedback from Chris Steipp.
Please comment. I've tried to sharpen the proposals down in to one thing we can do _right now_ which will do the most good for the most users. However, there are several other viable ideas which merit discussion and example implementations.
Thanks!
Steven _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sat, Jan 25, 2014 at 10:25 AM, Isarra Yos zhorishna@gmail.com wrote:
On 25/01/14 13:02, rupert THURNER wrote:
for the password policy: display a strength indicator is great. anything more? i would say just leave it to the user.
rupert.
This.
We should probably have this discussion on the RFC comments. The trade-off between security and user freedom is already brought up there, and there are some clarifying comments that are relevant. Namely, that the RFC is about the MediaWiki default. If a given MediWiki install wants to change the default, they can like all config settings.
On Sun, 26 Jan 2014, at 0:02, rupert THURNER wrote:
for the password policy: display a strength indicator is great. anything more? i would say just leave it to the user.
rupert.
THANK YOU. My thoughts exactly. :-)
Everyone who has a thought should write it on-wiki for these people to hear you without manually scanning a mailing list. Thanks.
gry
On Sun, Jan 26, 2014 at 9:49 AM, Gryllida gryllida@fastmail.fm wrote:
On Sun, 26 Jan 2014, at 0:02, rupert THURNER wrote:
for the password policy: display a strength indicator is great. anything more? i would say just leave it to the user.
rupert.
THANK YOU. My thoughts exactly. :-)
Everyone who has a thought should write it on-wiki for these people to hear you without manually scanning a mailing list. Thanks.
gry
I once saw a "can be brute forced on commodity hardware in x" field instead of an abstract "strength" field - but phrased less techy. I liked that.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
fde#@%62jtgjsl$#5kgsgjgseojgro@#$%SEGsgesjojahREAGHkerahj23YJ34pwyjw3$#^WrejgshSH
Time Required to Exhaustively Search this Password's Space:
Online Attack Scenario: 5.04 thousand trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries Offline Fast Attack Scenario: 50.42 million trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries Massive Cracking Array Scenario: 50.42 thousand trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries
Now just remember that password.
On Tue, Feb 4, 2014 at 10:18 AM, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Sun, Jan 26, 2014 at 9:49 AM, Gryllida gryllida@fastmail.fm wrote:
On Sun, 26 Jan 2014, at 0:02, rupert THURNER wrote:
for the password policy: display a strength indicator is great. anything more? i would say just leave it to the user.
rupert.
THANK YOU. My thoughts exactly. :-)
Everyone who has a thought should write it on-wiki for these people to hear you without manually scanning a mailing list. Thanks.
gry
I once saw a "can be brute forced on commodity hardware in x" field instead of an abstract "strength" field - but phrased less techy. I liked that.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Feb 4, 2014 at 10:33 AM, Petr Bena benapetr@gmail.com wrote:
fde#@%62jtgjsl$#5kgsgjgseojgro@ #$%SEGsgesjojahREAGHkerahj23YJ34pwyjw3$#^WrejgshSH (...) Now just remember that password.
All my passwords look like that and there is no need to remember them. You can use a password manager[1]. I am aware of the fact that most people on this list do not use one, and that people that are not technical do not even know what a password manager is.
Ċ½eljko -- 1: https://en.wikipedia.org/wiki/Password_manager
hacking into password manager might be easier than hacking into a human brain :P
On Tue, Feb 4, 2014 at 11:03 AM, Ċ½eljko Filipin zfilipin@wikimedia.org wrote:
On Tue, Feb 4, 2014 at 10:33 AM, Petr Bena benapetr@gmail.com wrote:
fde#@%62jtgjsl$#5kgsgjgseojgro@ #$%SEGsgesjojahREAGHkerahj23YJ34pwyjw3$#^WrejgshSH (...) Now just remember that password.
All my passwords look like that and there is no need to remember them. You can use a password manager[1]. I am aware of the fact that most people on this list do not use one, and that people that are not technical do not even know what a password manager is.
Ċ½eljko
1: https://en.wikipedia.org/wiki/Password_manager _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
To be honest one of things I liked most on wikipedia over other sites, was no password policy whatsoever. I hope we never get into such a creepy state like oracle website which requires so complicated password that I always immediately forget it...
On Tue, Feb 4, 2014 at 3:04 PM, Petr Bena benapetr@gmail.com wrote:
hacking into password manager might be easier than hacking into a human brain :P
On Tue, Feb 4, 2014 at 11:03 AM, Ċ½eljko Filipin zfilipin@wikimedia.org wrote:
On Tue, Feb 4, 2014 at 10:33 AM, Petr Bena benapetr@gmail.com wrote:
fde#@%62jtgjsl$#5kgsgjgseojgro@ #$%SEGsgesjojahREAGHkerahj23YJ34pwyjw3$#^WrejgshSH (...) Now just remember that password.
All my passwords look like that and there is no need to remember them. You can use a password manager[1]. I am aware of the fact that most people on this list do not use one, and that people that are not technical do not even know what a password manager is.
Ċ½eljko
1: https://en.wikipedia.org/wiki/Password_manager _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tuesday, February 4, 2014, Petr Bena benapetr@gmail.com wrote:
To be honest one of things I liked most on wikipedia over other sites, was no password policy whatsoever. I hope we never get into such a creepy state like oracle website which requires so complicated password that I always immediately forget it...
I fully agree. This is why the RFC explicitly
On Tue, Feb 4, 2014 at 3:04 PM, Petr Bena <benapetr@gmail.comjavascript:;> wrote:
hacking into password manager might be easier than hacking into a human
brain :P
On Tue, Feb 4, 2014 at 11:03 AM, Ċ½eljko Filipin <zfilipin@wikimedia.orgjavascript:;>
wrote:
On Tue, Feb 4, 2014 at 10:33 AM, Petr Bena <benapetr@gmail.comjavascript:;>
wrote:
fde#@%62jtgjsl$#5kgsgjgseojgro@ #$%SEGsgesjojahREAGHkerahj23YJ34pwyjw3$#^WrejgshSH (...) Now just remember that password.
All my passwords look like that and there is no need to remember them.
You
can use a password manager[1]. I am aware of the fact that most people
on
this list do not use one, and that people that are not technical do not even know what a password manager is.
Ċ½eljko
1: https://en.wikipedia.org/wiki/Password_manager _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Feb 4, 2014 at 11:58 AM, Steven Walling steven.walling@gmail.comwrote:
On Tuesday, February 4, 2014, Petr Bena benapetr@gmail.com wrote:
To be honest one of things I liked most on wikipedia over other sites, was no password policy whatsoever. I hope we never get into such a creepy state like oracle website which requires so complicated password that I always immediately forget it...
I fully agree. This is why the RFC explicitly
Sorry, was on my phone. I meant to say...
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 character types, such as mixed upper/lower case, numbers, symbols and so on. Just increasing the length, and hopefully suggesting to users how to pick a strong password, is plenty for MediaWiki defaults.
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 character types, such as mixed upper/lower case, numbers, symbols and so on. Just increasing the length, and hopefully suggesting to users how to pick a strong password, is plenty for MediaWiki defaults.
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, checkuser, etc.) should likely be treated differently.
Ultimately, account security is a user's prerogative. If a user wants to use "wiki" as his or her password, we can say that's not a great idea, but I don't see why we would outright ban it. Similarly, more complex passwords lead to people using a sticky note or similarly poor practices.
Wikimedia wiki accounts are nearly valueless. Banks and even e-mail providers have reason to implement stricter authentication requirements. Meanwhile on Wikimedia wikis, there's very little incentive to log in. What's the purpose of securing such standard accounts? This has an associated cost. What's the benefit?
Perhaps there are better arguments for why we should lock an unknown number of users out of their accounts every time someone upgrades MediaWiki, but currently the pros column seems a lot weaker than the cons column for implementing this change to $wgMinimalPasswordLength.
MZMcBride
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 job to enforce their own account security, what reason would banks or email providers have to require long passwords? If somebody guesses a user's password and empties their bank account, the bank could care less, since it is the customer's fault for not making sure their password is long enough.
Rather account security, and security in general, is a combination of both administrative oversight and user awareness. It is the system administrators' responsibility to try and make up for the fact that users are not security experts, and thus cannot be expected to take every possible measure to ensure the safety of their account. Accordingly it is our responsibility to set a password policy that ensures that users will not do something stupid, as all users are inclined to do.
Of course, it is still valid that a Wikimedia wiki account is "nearly valueless". However, that is probably more of a personal opinion than it is a fact. I'm sure a very heavy Wikipedia editor, who uses his/her account to make hundreds of edits a month but isn't necessarily an administrator or other higher-level user, sees their account as something more than a throwaway that can be replaced in an instant. Sure there is nothing of monetary value in the account, and no confidential information would be leaked should the account become compromised, but at the same time it has a personal value.
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, all your previous edits are still accredited to your previous account, and there's no way we can confirm you are the real MZMcBride, but at least you can continue to edit Wikipedia... Obviously you are not the best example, since I'm sure you have ways of confirming your identity to the Wikimedia Foundation, but not everybody is like that. You could argue that if you consider your Wikipedia account to have that much value, you'd put in the effort to make sure it is secure. To that I say see the above paragraph.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
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 AquaMail per Android http://www.aqua-mail.com
Il 05 febbraio 2014 08:59:24 Tyler Romeo tylerromeo@gmail.com ha scritto:
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 job to enforce their own account security, what reason would banks or email providers have to require long passwords? If somebody guesses a user's password and empties their bank account, the bank could care less, since it is the customer's fault for not making sure their password is long enough.
Rather account security, and security in general, is a combination of both administrative oversight and user awareness. It is the system administrators' responsibility to try and make up for the fact that users are not security experts, and thus cannot be expected to take every possible measure to ensure the safety of their account. Accordingly it is our responsibility to set a password policy that ensures that users will not do something stupid, as all users are inclined to do.
Of course, it is still valid that a Wikimedia wiki account is "nearly valueless". However, that is probably more of a personal opinion than it is a fact. I'm sure a very heavy Wikipedia editor, who uses his/her account to make hundreds of edits a month but isn't necessarily an administrator or other higher-level user, sees their account as something more than a throwaway that can be replaced in an instant. Sure there is nothing of monetary value in the account, and no confidential information would be leaked should the account become compromised, but at the same time it has a personal value.
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, all your previous edits are still accredited to your previous account, and there's no way we can confirm you are the real MZMcBride, but at least you can continue to edit Wikipedia... Obviously you are not the best example, since I'm sure you have ways of confirming your identity to the Wikimedia Foundation, but not everybody is like that. You could argue that if you consider your Wikipedia account to have that much value, you'd put in the effort to make sure it is secure. To that I say see the above paragraph.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Feb 5, 2014 at 2:58 AM, Tyler Romeo tylerromeo@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 sign up for Wikipedia again, using the username "MZMcBride2". Of course, all your previous edits are still accredited to your previous account, and there's no way we can confirm you are the real MZMcBride, but at least you can continue to edit Wikipedia... Obviously you are not the best example, since I'm sure you have ways of confirming your identity to the Wikimedia Foundation, but not everybody is like that. You could argue that if you consider your Wikipedia account to have that much value, you'd put in the effort to make sure it is secure. To that I say see the above paragraph.
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 foo@example.com, and I am emailing you from that account, so either my email account got compromised, or I am the person who first set an email address for user Foo." The email services have their own procedures for sorting out situations in which people claim their email accounts were hijacked.
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, all your previous edits are still accredited to your previous account, and there's no way we can confirm you are the real MZMcBride, but at least you can continue to edit Wikipedia... Obviously you are not the best example, since I'm sure you have ways of confirming your identity to the Wikimedia Foundation, but not everybody is like that. You could argue that if you consider your Wikipedia account to have that much value, you'd put in the effort to make sure it is secure. To that I say see the above paragraph.
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 foo@example.com, and I am emailing you from that account, so either my email account got compromised, or I am the person who first set an email address for user Foo." The email services have their own procedures for sorting out situations in which people claim their email accounts were hijacked.
I feel as though this idea does not meet my need for privacy. I can guess that at least a portion of the community would agree.
Thank you, Derric Atzrott
On Wed, Feb 5, 2014 at 4:12 AM, Nathan Larson nathanlarson3141@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 user Foo was foo@example.com, and I am emailing you from that account, so either my email account got compromised, or I am the person who first set an email address for user Foo." The email services have their own procedures for sorting out situations in which people claim their email accounts were hijacked.
This is definitely something to consider, but I feel like it would involve changing our privacy policy. Or at the very least it would cause some controversy related to that.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
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 job to enforce their own account security, what reason would banks or email providers have to require long passwords?
I'm not sure the logic is conflicting. I tried to separate individual thoughts into individual paragraphs. The common thread of my message was that I haven't yet seen enough evidence that the cost here is worth the benefit. The benefits to securing valueless accounts remains unclear, while the implementation cost is non-negligible.
E-mail accounts are often used in identity verification processes and banks are banks. While you and I may disagree with their password policies, there's at least a reasonable explanation for implementing more stringent requirements in these two cases. Compare with MediaWiki user accounts. What's the argument here? Why is this worth any effort?
I personally regularly use single-character passwords on test MediaWiki wikis (and other sites) because, as a user, it's my right to determine what value to place in a particular account.
If one day MediaWiki wikis (or Wikimedia wikis, really) allow per-user e-mail (i.e., mzmcbride@wikipedia.org) or if there comes a time when identity verification becomes part of the discussion (compare with Twitter's blue checkmark verified account practice), then it may make sense to require (l|str)onger passwords in those specific cases. Even today, if you want to make Jimmy or members of the Wikimedia Foundation staff have crazy-long passwords, that may be reasonable or prudent or what-have-you, but that doesn't mean MediaWiki core should go along.
If somebody guesses a user's password and empties their bank account, the bank could care less, since it is the customer's fault for not making sure their password is long enough.
I'm not sure this is true, but it's too off-topic to discuss here. A thread about global banking laws and practices, particularly with regard to liability and insurance and criminal activity, would certainly be interesting to read, though. :-)
I'm sure a very heavy Wikipedia editor, who uses his/her account to make hundreds of edits a month but isn't necessarily an administrator or other higher-level user, sees their account as something more than a throwaway that can be replaced in an instant.
I absolutely agree with you on this point. And I think we can encourage stronger passwords, even on the login form if you'd like. Rather than only using user groups, we could also use edit count or edit registration date or any number of other metrics. The catch, of course, is (a) finding developer consensus on a reasonable implementation of a password strength meter and (b) finding local community consensus to make changes on a per-variable basis.
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.
For what it's worth, I think I have one or two committed identities buried in my user page history on the English Wikipedia. In any case, as you note, it's mostly a moot point with me.
Finally, while not always the best precedent, it seems fair to look at the history here. As I recall (I'm relying on Cunningham's Law a little bit here ;-) UseModWiki and other early wiki engines allowed anonymous editing and even the ability to specify only a username when making an edit. MediaWiki itself used to allow completely blank passwords and people who are still active today used to have zero-length passwords. If history is any guide here, the idea that standard wiki accounts, and even online identity, is not particularly valuable is not new in the wiki world. Perhaps it's no longer the case today, but there was (and hopefully is) a noble goal to encourage a strong focus primarily on the content rather than the contributor. A lofty goal, indeed.
MZMcBride
On Wed, Feb 5, 2014 at 8:00 PM, MZMcBride z@mzmcbride.com wrote:
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 job to enforce their own account security, what reason would banks or email providers have to require long passwords?
I'm not sure the logic is conflicting. I tried to separate individual thoughts into individual paragraphs. The common thread of my message was that I haven't yet seen enough evidence that the cost here is worth the benefit. The benefits to securing valueless accounts remains unclear, while the implementation cost is non-negligible.
E-mail accounts are often used in identity verification processes and banks are banks. While you and I may disagree with their password policies, there's at least a reasonable explanation for implementing more stringent requirements in these two cases. Compare with MediaWiki user accounts. What's the argument here? Why is this worth any effort?
I think there are a couple of reasons why we have a duty to enforce strong passwords. Let me try to convince you.
1) As I understand it, the reason we went from 0 to 1 character required is spammers were actively trying to find accounts with no password so they could edit with an autoconfirmed account. We rely on "number of combinations of minimum passwords" to be greater than "number of tries before an IP must also solve captcha to login" to mitigate some of this, but I think there are straightforward ways for a spammer to get accounts with our current setup. And I think increasing the minimum password length is one component.
2) We do have a duty to protect our user's accounts with a reasonable amount of effort/cost proportional to the weight we put on those identities. I think we would be in a very difficult spot if the foundation tried to take legal action against someone for the actions they took with their user account, and the user said, "That wasn't me, my account probably got hacked. And it's not my fault, because I did the minimum you asked me." So I think we at least want to be roughly in line with "industry standard", or have a calculated tradeoff against that, which is roughly 6-8 character passwords with no complexity requirements. I personally think the foundation and community _does_ put quite a lot of weight into user's identities (most disputes and voting processes that I've seen have some component that assume edits by an account were done by a single person), so I think we do have a responsibility to set the bar at a level appropriate to that, assuming that all users will do the minimum that we ask. Whether it's 4 or 6 characters for us I think is debatable, but I think 1 is not reasonable.
I personally regularly use single-character passwords on test MediaWiki wikis (and other sites) because, as a user, it's my right to determine what value to place in a particular account.
If one day MediaWiki wikis (or Wikimedia wikis, really) allow per-user e-mail (i.e., mzmcbride@wikipedia.org) or if there comes a time when identity verification becomes part of the discussion (compare with Twitter's blue checkmark verified account practice), then it may make sense to require (l|str)onger passwords in those specific cases. Even today, if you want to make Jimmy or members of the Wikimedia Foundation staff have crazy-long passwords, that may be reasonable or prudent or what-have-you, but that doesn't mean MediaWiki core should go along.
If somebody guesses a user's password and empties their bank account, the bank could care less, since it is the customer's fault for not making sure their password is long enough.
I'm not sure this is true, but it's too off-topic to discuss here. A thread about global banking laws and practices, particularly with regard to liability and insurance and criminal activity, would certainly be interesting to read, though. :-)
I'm sure a very heavy Wikipedia editor, who uses his/her account to make hundreds of edits a month but isn't necessarily an administrator or other higher-level user, sees their account as something more than a throwaway that can be replaced in an instant.
I absolutely agree with you on this point. And I think we can encourage stronger passwords, even on the login form if you'd like. Rather than only using user groups, we could also use edit count or edit registration date or any number of other metrics. The catch, of course, is (a) finding developer consensus on a reasonable implementation of a password strength meter and (b) finding local community consensus to make changes on a per-variable basis.
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.
For what it's worth, I think I have one or two committed identities buried in my user page history on the English Wikipedia. In any case, as you note, it's mostly a moot point with me.
Finally, while not always the best precedent, it seems fair to look at the history here. As I recall (I'm relying on Cunningham's Law a little bit here ;-) UseModWiki and other early wiki engines allowed anonymous editing and even the ability to specify only a username when making an edit. MediaWiki itself used to allow completely blank passwords and people who are still active today used to have zero-length passwords. If history is any guide here, the idea that standard wiki accounts, and even online identity, is not particularly valuable is not new in the wiki world. Perhaps it's no longer the case today, but there was (and hopefully is) a noble goal to encourage a strong focus primarily on the content rather than the contributor. A lofty goal, indeed.
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Feb 6, 2014 at 9:58 AM, Chris Steipp csteipp@wikimedia.org wrote:
- As I understand it, the reason we went from 0 to 1 character required is
spammers were actively trying to find accounts with no password so they could edit with an autoconfirmed account. We rely on "number of combinations of minimum passwords" to be greater than "number of tries before an IP must also solve captcha to login" to mitigate some of this, but I think there are straightforward ways for a spammer to get accounts with our current setup. And I think increasing the minimum password length is one component.
- We do have a duty to protect our user's accounts with a reasonable
amount of effort/cost proportional to the weight we put on those identities. I think we would be in a very difficult spot if the foundation tried to take legal action against someone for the actions they took with their user account, and the user said, "That wasn't me, my account probably got hacked. And it's not my fault, because I did the minimum you asked me." So I think we at least want to be roughly in line with "industry standard", or have a calculated tradeoff against that, which is roughly 6-8 character passwords with no complexity requirements. I personally think the foundation and community _does_ put quite a lot of weight into user's identities (most disputes and voting processes that I've seen have some component that assume edits by an account were done by a single person), so I think we do have a responsibility to set the bar at a level appropriate to that, assuming that all users will do the minimum that we ask. Whether it's 4 or 6 characters for us I think is debatable, but I think 1 is not reasonable.
1) Merely increasing the length could increase required keystrokes without making it more secure. A couple comments from the meetinghttps://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-05#Full_log : <brion> "aaaaaaaaaaaaaaaaaaaaaaaa" ain't secure <TimStarling> "password" isn't secure either, and that's 8
It seems to me that a pretty secure approach would be to have the system give the user his 8-12 character password, rather than letting him pick a password. Then we can be assured that he's not doing stuff like "p@ssword" to meet the complexity requirements.
2) How plausible is this scenario you mention, involving legal action? Has/would the WMF ever take/taken legal action against someone for actions taken with their user account? Why would that happen, when any damage done by a non-checkuser can generally be reverted/deleted/etc.? What would be the remedy; trying to get money out of the person? It probably wouldn't amount to much.
<brion> "aaaaaaaaaaaaaaaaaaaaaaaa" ain't secure <TimStarling> "password" isn't secure either, and that's 8
It seems to me that a pretty secure approach would be to have the system give the user his 8-12 character password, rather than letting him pick a password. Then we can be assured that he's not doing stuff like "p@ssword" to meet the complexity requirements.
Well if we are going to go down that road, requring public/private key pairs would also be more secure. However i doubt either would be acceptable to users.
-bawolff
On Thu, Feb 6, 2014 at 3:26 PM, Brian Wolff bawolff@gmail.com wrote:
Well if we are going to go down that road, requring public/private key pairs would also be more secure. However i doubt either would be acceptable to users.
Actually, I think it might be better if we just have people come on down to the San Francisco office and show their government ID. Then we have Tim or Brion log them in personally. ;)
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
Well if we are going to go down that road, requring public/private key pairs would also be more secure. However i doubt either would be acceptable to users.
Actually, I think it might be better if we just have people come on down to the San Francisco office and show their government ID. Then we have Tim or Brion log them in personally. ;)
Actually to be honest, if I could login to Mediawiki with a public/private keypair I would actually really enjoy that. Certainly it shouldn't be the default, but in a very non-joking way, I would support an initiative to add that as an option.
Thank you, Derric Atzrott
On Thu, Feb 6, 2014 at 4:54 PM, Derric Atzrott <datzrott@alizeepathology.com
wrote:
Actually to be honest, if I could login to Mediawiki with a public/private keypair I would actually really enjoy that. Certainly it shouldn't be the default, but in a very non-joking way, I would support an initiative to add that as an option.
You mean kind of like this? https://www.mediawiki.org/wiki/Extension:SSLClientAuthentication
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
Actually to be honest, if I could login to Mediawiki with a public/private keypair I would actually really enjoy that. Certainly it shouldn't be the default, but in a very non-joking way, I would support an initiative to add that as an option.
You mean kind of like this? https://www.mediawiki.org/wiki/Extension:SSLClientAuthentication
Pretty close. I was actually thinking well known PGP keypair, but SSL cert signed by a trusted CA works just as well. I'll fool around with that extension later today. Thank you!
Thank you, Derric Atzrott
Nathan Larson nathanlarson3141@gmail.com wrote:
[...]
- How plausible is this scenario you mention, involving legal action?
Has/would the WMF ever take/taken legal action against someone for actions taken with their user account? Why would that happen, when any damage done by a non-checkuser can generally be reverted/deleted/etc.? What would be the remedy; trying to get money out of the person? It probably wouldn't amount to much.
Cf. http://blog.wikimedia.org/2013/11/19/wikimedia-foundation-sends-cease-and-de....
Tim
Chris Steipp wrote:
- As I understand it, the reason we went from 0 to 1 character required
is spammers were actively trying to find accounts with no password so they could edit with an autoconfirmed account.
Err, citation needed. :-)
I'd forgotten that I'd filed https://bugzilla.wikimedia.org/18222 (related to MediaWiki core rather than Wikimedia). I thought the change from 0 to 1 for this variable generally was due to integration issues with other authentication systems, but I have no idea why I think this. I looked at an older version of Wikimedia's InitialiseSettings.php and found only the accompanying code comment "enforce prohibition of blank passwords" (the $wgMinimalPasswordLength variable was presumably subsequently removed when someone noticed that its value matched the software default value). I didn't see any relevant entries in the Wikimedia server admin log in my brief search.
Arguing to increase minimal password length as an anti-spam measure is reasonable provided that there's an actual (i.e., demonstrable) issue that needs to be addressed and that there's good reason to believe that this particular measure will mitigate that issue. However, if there isn't evidence to suggest that this is an effective anti-spam approach, a needless increase in the default value of this variable has the taste of security theater.
- We do have a duty to protect our user's accounts with a reasonable
amount of effort/cost proportional to the weight we put on those identities. I think we would be in a very difficult spot if the foundation tried to take legal action against someone for the actions they took with their user account, and the user said, "That wasn't me, my account probably got hacked. And it's not my fault, because I did the minimum you asked me."
With respect, I think this is an unfair argument to make. It strikes me as a rough appeal to authority (legal consequences) without any kind of reference or substantiation. If you think that the setting of $wgMinimalPasswordLength in MediaWiki core or on Wikimedia wikis is a legal issue, you should consult with the Wikimedia Foundation legal team. I don't think it's fair to use legal theories and speculation as a basis for changing software settings. The fact that most users can edit while logged out ("anonymously") also seems to poke large holes in this idea.
Whether it's 4 or 6 characters for us I think is debatable, but I think 1 is not reasonable.
Minimal password length has been configurable since January 2005 (cf. https://www.mediawiki.org/wiki/Special:Code/MediaWiki/48968) and no Wikimedia wiki community has asked for it to be increased in all these years, as far as I'm aware (I looked around Bugzilla). I think most users feel that account maintenance is a personal responsibility issue. As discussed at https://bugzilla.wikimedia.org/25925 it's a matter of convenience versus security.
If you want to set the value of $wgMinimalPasswordLength higher for officewiki or other private Wikimedia wikis, that's obviously (at least partially) your prerogative. But for MediaWiki core and for standard Wikimedia wikis, I'd like there to be a decent rationale before we consider inconveniencing users.
MZMcBride
P.S. I also casually wonder whether there's a reasonable argument to be made here that requiring longer passwords will hurt editor retention more than it helps, but this thought is still largely unformed and unfocused.
If feel like I should reiterate why I proposed this change. Maybe no one cares, but I think it might help convince folks this is NOT an argument for "let's reduce user freedom in the name of security."
I didn't worked on the RFC because I love tinkering with password security in my spare time and know lots about it. Far from it. I did it because I think we're failing MediaWiki users on *all installations* by inviting them to sign up for an account, and then failing to set default requirements that help them adequately secure those accounts. Users tend to follow defaults and do the minimum effort to reach their goals -- in this case to sign up and then get editing. It's our job as the MediaWiki designers and developers to set good defaults that encourage account security without being excessively annoying.
In addition to just being sane about security defaults, there is more. Allow me to wax poetic a moment... If you can edit anonymously, why do we allow and encourage registration at all? Many reasons of course, but one of them is because it is a rewarding experience to have a persistent identity on a wiki. We all know how real that identity becomes sometimes. When I meet Krinkle or MZMcbride in real life, I don't call them Timo and Max. Or if I do, I don't think of them as those names in my head.
When wiki users start an account, they might think that they are just creating something unimportant. They may actually have bad intentions. But part of this is that we're offering people an account because it gives them a chance to be recognized, implicitly and explicitly, for the work they do on our wikis.
I think setting a default of 1 character passwords required doesn't reinforce the idea that an account is something you might actually come to cherish a bit, and that it might even represent you in some important way to others. By signaling to new users that an account is so worthless that it's cool if you have a one character password... well, is that really such a good thing?
On Thu, Feb 6, 2014 at 5:44 PM, MZMcBride z@mzmcbride.com wrote:
P.S. I also casually wonder whether there's a reasonable argument to be made here that requiring longer passwords will hurt editor retention more than it helps, but this thought is still largely unformed and unfocused.
I think that's a canard. There are many many sites that do not have user acquisition or retention problems, while also having sane password length requirements. Yes, this is a potential extra roadblock, which may slightly reduce conversion rates on the signup form by slowing people down. However, one of the clear arguments in favor of doing this now (as opposed to say, back in 2001) is that users will largely expect an account on a popular website to require them to have a password longer than 1 character.
If we really are scared about the requirements in our signup form driving people away from editing, we can make many user experience improvements that would, like every other site, offset the terrible awful horrible evil of requiring a six character password. I'd be happy to list specifics if someone wants, but this email is already too long.
Steven
On 2/7/14, Steven Walling steven.walling@gmail.com wrote:
If feel like I should reiterate why I proposed this change. Maybe no one cares, but I think it might help convince folks this is NOT an argument for "let's reduce user freedom in the name of security."
I didn't worked on the RFC because I love tinkering with password security in my spare time and know lots about it. Far from it. I did it because I think we're failing MediaWiki users on *all installations* by inviting them to sign up for an account, and then failing to set default requirements that help them adequately secure those accounts. Users tend to follow defaults and do the minimum effort to reach their goals -- in this case to sign up and then get editing. It's our job as the MediaWiki designers and developers to set good defaults that encourage account security without being excessively annoying.
In addition to just being sane about security defaults, there is more. Allow me to wax poetic a moment... If you can edit anonymously, why do we allow and encourage registration at all? Many reasons of course, but one of them is because it is a rewarding experience to have a persistent identity on a wiki. We all know how real that identity becomes sometimes. When I meet Krinkle or MZMcbride in real life, I don't call them Timo and Max. Or if I do, I don't think of them as those names in my head.
When wiki users start an account, they might think that they are just creating something unimportant. They may actually have bad intentions. But part of this is that we're offering people an account because it gives them a chance to be recognized, implicitly and explicitly, for the work they do on our wikis.
I think setting a default of 1 character passwords required doesn't reinforce the idea that an account is something you might actually come to cherish a bit, and that it might even represent you in some important way to others. By signaling to new users that an account is so worthless that it's cool if you have a one character password... well, is that really such a good thing?
On Thu, Feb 6, 2014 at 5:44 PM, MZMcBride z@mzmcbride.com wrote:
P.S. I also casually wonder whether there's a reasonable argument to be made here that requiring longer passwords will hurt editor retention more than it helps, but this thought is still largely unformed and unfocused.
I think that's a canard. There are many many sites that do not have user acquisition or retention problems, while also having sane password length requirements. Yes, this is a potential extra roadblock, which may slightly reduce conversion rates on the signup form by slowing people down. However, one of the clear arguments in favor of doing this now (as opposed to say, back in 2001) is that users will largely expect an account on a popular website to require them to have a password longer than 1 character.
If we really are scared about the requirements in our signup form driving people away from editing, we can make many user experience improvements that would, like every other site, offset the terrible awful horrible evil of requiring a six character password. I'd be happy to list specifics if someone wants, but this email is already too long.
Steven _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thanks for the background, I think its important to know the "why" for a change, not just a what. However it doesn't address what I see as the main concern being raised about this proposal - the lack of a threat model. Who is the enemy we're concerned about breaking into accounts? What is the enemy's resources? Anything done for security should be in reference to some sort of threat model. Otherwise we will probably end up implementing security that does not make sense, things that protect one aspect without protecting the important aspect, etc. Well most people think having distinct identities on wiki is important, what we need to protect them from is going to vary wildly from person to person. It wouldn't surprise me if the hard-core SoftSecurity people would argue for an honour system...
Users tend to follow defaults and do the minimum effort to reach their goals -- in this case to sign up and then get editing.
'password' is probably less secure than most one letter passwords.
--bawolff
p.s. I don't think stronger password requirements will have much of an affect on user retention assuming the requirements aren't insane (e.g. Don't require a password min 9 max 13 characters long with exactly 7 symbols and no more than 2 numbers)
On Sat, Feb 8, 2014 at 8:14 AM, Brian Wolff bawolff@gmail.com wrote:
On 2/7/14, Steven Walling steven.walling@gmail.com wrote:
If feel like I should reiterate why I proposed this change. Maybe no one cares, but I think it might help convince folks this is NOT an argument
for
"let's reduce user freedom in the name of security."
I didn't worked on the RFC because I love tinkering with password
security
in my spare time and know lots about it. Far from it. I did it because I think we're failing MediaWiki users on *all installations* by inviting
them
to sign up for an account, and then failing to set default requirements that help them adequately secure those accounts. Users tend to follow defaults and do the minimum effort to reach their goals -- in this case
to
sign up and then get editing. It's our job as the MediaWiki designers and developers to set good defaults that encourage account security without being excessively annoying.
In addition to just being sane about security defaults, there is more. Allow me to wax poetic a moment... If you can edit anonymously, why do we allow and encourage registration at all? Many reasons of course, but one
of
them is because it is a rewarding experience to have a persistent
identity
on a wiki. We all know how real that identity becomes sometimes. When I meet Krinkle or MZMcbride in real life, I don't call them Timo and Max.
Or
if I do, I don't think of them as those names in my head.
When wiki users start an account, they might think that they are just creating something unimportant. They may actually have bad intentions.
But
part of this is that we're offering people an account because it gives
them
a chance to be recognized, implicitly and explicitly, for the work they
do
on our wikis.
I think setting a default of 1 character passwords required doesn't reinforce the idea that an account is something you might actually come
to
cherish a bit, and that it might even represent you in some important way to others. By signaling to new users that an account is so worthless that it's cool if you have a one character password... well, is that really
such
a good thing?
On Thu, Feb 6, 2014 at 5:44 PM, MZMcBride z@mzmcbride.com wrote:
P.S. I also casually wonder whether there's a reasonable argument to be made here that requiring longer passwords will hurt editor retention
more
than it helps, but this thought is still largely unformed and unfocused.
I think that's a canard. There are many many sites that do not have user acquisition or retention problems, while also having sane password length requirements. Yes, this is a potential extra roadblock, which may
slightly
reduce conversion rates on the signup form by slowing people down.
However,
one of the clear arguments in favor of doing this now (as opposed to say, back in 2001) is that users will largely expect an account on a popular website to require them to have a password longer than 1 character.
If we really are scared about the requirements in our signup form driving people away from editing, we can make many user experience improvements that would, like every other site, offset the terrible awful horrible
evil
of requiring a six character password. I'd be happy to list specifics if someone wants, but this email is already too long.
Steven _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thanks for the background, I think its important to know the "why" for a change, not just a what. However it doesn't address what I see as the main concern being raised about this proposal - the lack of a threat model. Who is the enemy we're concerned about breaking into accounts? What is the enemy's resources? Anything done for security should be in reference to some sort of threat model. Otherwise we will probably end up implementing security that does not make sense, things that protect one aspect without protecting the important aspect, etc. Well most people think having distinct identities on wiki is important, what we need to protect them from is going to vary wildly from person to person. It wouldn't surprise me if the hard-core SoftSecurity people would argue for an honour system...
Totally agree, and I added a first pass for it at https://www.mediawiki.org/wiki/Requests_for_comment/Passwords#Threats
Users tend to follow defaults and do the minimum effort to reach their goals -- in this case
to
sign up and then get editing.
'password' is probably less secure than most one letter passwords.
--bawolff
p.s. I don't think stronger password requirements will have much of an affect on user retention assuming the requirements aren't insane (e.g. Don't require a password min 9 max 13 characters long with exactly 7 symbols and no more than 2 numbers)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Chris Steipp wrote:
Totally agree, and I added a first pass for it at https://www.mediawiki.org/wiki/Requests_for_comment/Passwords#Threats
Thanks for this. I think it's a good start. I think it's reasonable to say that you've established that there are threats. In my opinion, now it's a matter of demonstrating that any counter-measures proposed will directly mitigate those threats. And it's also a matter of demonstrating that the threats are substantial (dangerous) enough to warrant a response. There are nearly a limitless number of threats in life, so figuring out how much energy to invest in securing free and unprivileged accounts versus administrator or steward accounts is important.
Just to give a better understanding, for the English Wikipedia as of about Wed Feb 12 03:44:04 UTC 2014:
MariaDB [enwiki_p]> select user_editcount, count(user_id) from user group by user_editcount order by user_editcount asc limit 11; +----------------+----------------+ | user_editcount | count(user_id) | +----------------+----------------+ | 0 | 13814964 | | 1 | 2406240 | | 2 | 1151354 | | 3 | 664263 | | 4 | 436915 | | 5 | 309483 | | 6 | 231616 | | 7 | 178952 | | 8 | 143525 | | 9 | 116164 | | 10 | 96053 | +----------------+----------------+ 11 rows in set (38.93 sec)
Pastebin: http://p.defau.lt/?4QMxue_aRSm1eK9CEK_wDw
There are approximately 20,740,377 user accounts total, so roughly 66.61% of accounts have zero edits and roughly 94.26% of accounts have ten or fewer edits on the English Wikipedia. A few thousand of these users are likely involved in substantial work on other wikis, but that's probably a nearly insignificant percentage. The convenience versus security trade-off is still a serious consideration, in my opinion.
MZMcBride
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 complex character types, such as mixed upper/lower case, numbers, symbols and so on. Just increasing the length, and hopefully suggesting to users how to pick a strong password, is plenty for MediaWiki defaults.
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, checkuser, etc.) should likely be treated differently.
Ultimately, account security is a user's prerogative. If a user wants to use "wiki" as his or her password, we can say that's not a great idea, but I don't see why we would outright ban it. Similarly, more complex passwords lead to people using a sticky note or similarly poor practices.
Wikimedia wiki accounts are nearly valueless. Banks and even e-mail providers have reason to implement stricter authentication requirements. Meanwhile on Wikimedia wikis, there's very little incentive to log in. What's the purpose of securing such standard accounts? This has an associated cost. What's the benefit?
Perhaps there are better arguments for why we should lock an unknown number of users out of their accounts every time someone upgrades MediaWiki, but currently the pros column seems a lot weaker than the cons column for implementing this change to $wgMinimalPasswordLength.
MZMcBride
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 password can be brute forced in x"). If users are then not deterred from setting their password to "wiki", apparently they didn't care, as we told them how easy it is to brute force.
If Steven did mean something that will lock people out of their account on upgrades, then I don't think that's a good idea at all.
Martijn.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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 password can be brute forced in x"). If users are then not deterred from setting their password to "wiki", apparently they didn't care, as we told them how easy it is to brute force.
I think such statistics are misleading. Why would an attacker use brute force over a dictionary attack?
-bawolff
On Tue, Feb 4, 2014 at 11:59 PM, Martijn Hoekstra <martijnhoekstra@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 user about password strength when they set them (see my earlier post about "this password can be brute forced in x"). If users are then not deterred from setting their password to "wiki", apparently they didn't care, as we told them how easy it is to brute force.
We do not mean for new accounts only. We mean for all accounts.
If Steven did mean something that will lock people out of their account on upgrades, then I don't think that's a good idea at all.
We will not lock people who are using their accounts out. The RFC explicitly mentions two things which will help us having people avoid being locked out of their account:
1. Being extremely loud about announcing the change. We have used cluster-wide banners for this kind of purpose before. 2. As described in the RFC, there is a patch undergoing review which will make it possible to force a reset *after* the user logs in again.
In any case, this RFC is about the MediaWiki default. If we want to set the MediaWiki default in core but wait to update Wikimedia sites until we are sure we won't lock a bunch of active users out of their accounts we can do that. We should separate out the rollout strategy from whether we think that a minimum password length is a good default in MediaWiki.
On Tue, Feb 4, 2014 at 11:20 PM, MZMcBride z@mzmcbride.com 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, checkuser, etc.) should likely be treated differently.
That does not seem to be the consensus to me. I see several people with expertise in this area (Chris Steipp, Ryan Lane, others) recommending that this is the least we should do. I think we should leave determining consensus up to the people who will close the RFC.
On Tue, Feb 4, 2014 at 1:33 AM, Petr Bena benapetr@gmail.com wrote:
Now just remember that password.
I think that issue has been solved quite a while ago, you don't remember passwords, you keep them in password stores. you may have a master password to remember but you don't have the same on all services and you don't remember the individual ones, you copy/paste, so i don't care at all how long it is
A three/four colour lamp + "it might be forced in approx X days" sounds great!
Vito
Inviato con AquaMail per Android http://www.aqua-mail.com
Il 04 febbraio 2014 10:19:12 Martijn Hoekstra martijnhoekstra@gmail.com ha scritto:
On Sun, Jan 26, 2014 at 9:49 AM, Gryllida gryllida@fastmail.fm wrote:
On Sun, 26 Jan 2014, at 0:02, rupert THURNER wrote:
for the password policy: display a strength indicator is great. anything more? i would say just leave it to the user.
rupert.
THANK YOU. My thoughts exactly. :-)
Everyone who has a thought should write it on-wiki for these people to hear you without manually scanning a mailing list. Thanks.
gry
I once saw a "can be brute forced on commodity hardware in x" field instead of an abstract "strength" field - but phrased less techy. I liked that.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I like how we got these things done early in the process: - termed the proposal as 'improve password policy', in the subject, implying that the solution is good - instead of asking how to do it - put a single proposal, raising the requirement, instead of putting a few proposed changes and asking which one people would like to pick
My feeling is that there should be some guidelines, encouraging to shape questions and ask how to do things rather than propose a single change. It's what happens anyway, and putting it right the first time could be less confusing and encourage feedback by claiming an open question with suggested alternative solutions.
wikitech-l@lists.wikimedia.org