fwiw, this isn't really about distruting admins so much as making sure that the person we trusted is the person who is in control of the account. BWolff (WMF) (talk) 18:14, 13 December 2015 (UTC)[reply]
It's perfectly reasonable to set up password requirements for admins (or higher), regardless of how much you trust them, when they have access to security-sensitive rights. --Krenair(talk • contribs)18:18, 13 December 2015 (UTC)[reply]
When decided whether to trust someone, do you really investigate their account security? Or do you really just trust nobody? Your position is unacceptable from a security point of view. Anyway, I'll echo what Brian said above - this is about making sure the person logging into a privileged account is indeed the person we trusted with the rights that account has granted. --Krenair(talk • contribs)19:38, 13 December 2015 (UTC)[reply]
I would rather tend to say "investigat[ing] […] account security" is close to impossible, regardless if this proposal is implemented or not. Even if such password requirements were enforced, we would still need to trust the affected users not to use alternative, but yet equally "simple" passwords, not to use the same password across multiple platforms (which was btw the reason for the enwiki issue), etc. pp. I doubt the effectiveness of the proposed measure, it merely adds extra-code to the software. I understand why one would recommend passwords as it's been done in this proposal, but I disagree enforcing this by software is a useful thing. --Vogone (talk) 22:35, 13 December 2015 (UTC)[reply]
We can only do so much in the software. This is not an issue of trust but of "we literally can't fix those problems". Your argument then seems to be that "longer passwords are not more secure", which is patently false, regardless whether a user drops "aaaaaaaa" into his "Enter password" field or drops a "!@#SQWtXZwAW3" into it. If there is an argument you should be making, it's that "limiting attempts to access a user account" is probably the most effective way to counter server-side loss-of-account, a policy I'm unsure whether Wikimedia enables on its wikis (I haven't tried to break into an account of late...). As you suggest, we can't do anything about user-idiocy. --Izno (talk) 14:37, 14 December 2015 (UTC)[reply]
The position that I might trust administrators with whom I have never interacted pretty quickly sets this comment into the "dumb comments" piles. In that case, it is not that I trust them but that I have no evidence with which to distrust them, or that I simply do not know of them, meaning I don't care whether I trust or distrust them. Trust is not binary. --Izno (talk) 14:37, 14 December 2015 (UTC)[reply]
Because I don't want it. If you want it, per Vogone, MF-W, Ajr. Why don't you ask the same questions for supporters? — regards, Revi13:44, 14 December 2015 (UTC)[reply]
Apparently the case on enwiki was the first in years globally where such a thing happened. I do not see any reason from it to introduce these global requirements. Also, I do not understand why this RFC is set up in adversiarial style (where there are even fancy buttons for adding a comment, instead of the edit section link, yikes?!) instead of a discussion section where arguments can be exchanged. --MF-W16:51, 13 December 2015 (UTC)[reply]
I thought the sections might be easier if the audiance might not all speak the same language. People should feel free to comment on other people's comments and exchange ideas as they see fit. The fancy buttons instead of edit sections is so that we can have subpages for the comments (in the hopes that makes translating the proposal easier) without the edit links going to the page where the header is instead of the subpage. I modelled the formatting of this RFC on the freebassel one. I'm not usually imvolved with these sorts of things so I dont know if its the best choice but it seemed reasonable at the time. BWolff (WMF) (talk) 18:14, 13 December 2015 (UTC)[reply]
What's so scary about the fancy buttons linking to edit section instead of a normal link? It's not like you can't still comment on other's messages. And there's still a generic comment section below. --Krenair(talk • contribs)18:18, 13 December 2015 (UTC)[reply]
The button design looks like it will automatically vote (eg. vote «Oppose»), instead of allowing you to comment the Oppose section. I also think a normal link would be beneficial. Platonides (talk) 23:04, 13 December 2015 (UTC)[reply]
Oppose. Six random characters is secure enough, whereas one eight-letter common word isn't. Trying to enforce a certain level of entropy doesn't work. I think it's reasonable to assume the admins have some common sense when choosing passwords, and some existing secure passwords will probably need to be changed as a result of this. Sacrificing enough usability for security leads to losing security. Asking people to create new passwords means that you'll have a mess of people having difficulty remembering their new passwords, and trying to store their passwords in places in a very insecure manner, and some making passwords that are easy to remember at the cost of security. Forcing admins to change passwords from their long-used "Q´a8Z/" to "password" (or some less-exaggeratedly simple password) is a terrible idea. --Yair rand (talk) 18:37, 13 December 2015 (UTC)[reply]
This rig, dating from 2010, can check Microsoft's NTLM hash of every six-character password in two seconds. I appreciate that PBKDF2 is a considerable improvement, but eight random characters will always take almost 10,000 times longer to crack than random six characters. Is the increased difficulty in remembering eight characters rather than six worth that much weaker security? --RexxS (talk) 15:10, 14 December 2015 (UTC)[reply]
I'm pretty sure I didn't misread his statement "Six random characters is secure enough". That's patently a false premise. --RexxS (talk) 12:13, 21 December 2015 (UTC)[reply]
The point I am making about your response is that you are making a false comparison. From what I can see, and why we are advised to use random passwords to begin with, is that a dictionary attack is more likely than a brute force, making an 8 character single word passphrase less secure than 6 random characters. The argument he's making isn't the best regardless, but your counterargument doesn't seem to accept the above fact either. --Izno (talk) 20:57, 21 December 2015 (UTC)[reply]
That site assumes the attacker can make 4 billion guesses a second. How many guesses an attacker can make a second depends on the attack model, and can be much higher than most people think... but 4 billion sounds a bit unrealistic to me in Wikimedia's setup (If we were using a plain hash instead of PBKDF, 4 billion might be realistic for an offline attacker). As for Yair rand's example 7 byte password ('´' is a non-ascii character and takes 2 bytes. Its also not on english keyboards, which might make it less likely to be hit by a dictionary attack). It would be secure against a brute force attacker who can do 1000/guesses a second (but pretty much just barely, probably). It might not be secure against a more powerful attacker. The security margin is less than what I would like to see on an admin account, but if I'm being honest, he's definitely correct that it would be much more secure than someone who chooses a poor 8 byte password. That said, an 8 byte password chosen in a similar good fashion would have a much higher security margin, and be very unlikely to be cracked. BWolff (WMF) (talk) 11:24, 22 December 2015 (UTC)[reply]
Per Vogone, I trust advanced permissions holders to have secure passwords. If you're very concerned about security, have a two-factor authentication option available for use. Ajraddatz (talk) 22:40, 13 December 2015 (UTC)[reply]
The people who would use a second factor if it was available are not the ones whose security we should be most concerned about. --Tgr (talk) 23:10, 13 December 2015 (UTC)[reply]
Nope, but if you trust advanced permissions holders to keep their accounts secure, then you can focus effort on other technical issues :-) Ajraddatz (talk) 23:59, 13 December 2015 (UTC)[reply]
attackers go after the weakest link, not the links we want them to go after. Sure if we pretend the problem doesnt exist we could focus on other things (however, i would note that the technical work is already done, so its not like voting no saves effort). But that wouldnt do us any good as the things we are ignoring are the weak points. BWolff (WMF) (talk) 00:18, 14 December 2015 (UTC)[reply]
Doesn't make any sense, IMHO. Though in general I'm fine with the proposal, it is clear that the holders of the rights mentioned must keep their accs safe, that's not a solution. It's like wasting money on security door (in this case we are speaking about not money but complicating code, probably making some operations run slower even if just a fraction of operations and just a fraction of speed) while the walls are made of plasterboard (and by this I mean email password on which we have no influence). I must a little bit disagree with Vogone though, while I trust most admins, in some projects, especially but not exceptionally in small ones, admin-flags are given not to (just) technically competent users but also/just as an award for good considerable contributions. Some people could just be ignorant of both the power admin flag provides and the means of account security necessary. --Base (talk) 22:28, 18 December 2015 (UTC)[reply]
No, thanks. I'm really pissed of password-strength policy at my ex-ex-workplace. Because of stupid "have very secure password and change it every N days" people started to write down their passwords on sheets of paper. As experienced user I do understand what password is secure and what is not. Either you believe that i'm experienced enough to edit common.js AND select my own password by myself, or do not grant me any additional rights. -- Vlsergey-at-work (talk) 08:53, 21 December 2015 (UTC)[reply]
Bad idea. A strong password in itself is not a panacea, and the problem here is not the strength of their passwords, but the fact it's a single point of falure. Passwords can be stolen in various ways, people can be socially engineered, etc. Introduce some code review process for these sensitive files so that at least two or better three admins see the changes before they go live. Also, one-time password support for logging in on untrusted machines would be much more useful. --Yury Bulka (talk) 10:32, 21 December 2015 (UTC)[reply]
Strongly oppose. I have seen enough domains where password has to be changed on the regular basis. This results in storing the passwords in insecure way. Here we discuss single password change but for a lot of users in short time, thus kind of a heaven for hackers. Sir Shurf (talk) 10:53, 21 December 2015 (UTC)[reply]
Just to be clear, we are not proposing that passwords would have to be changed on a regular basis. I would strongly oppose that type of measure since mandatory regular password changes are a royal pain, and there's about a million research articles on how requiring regular password changes reduces overall security. I just want people to be using a secure password that's not easily guessable. Hopefully most people already are, and they wouldn't even notice the change. BWolff (WMF) (talk) 11:09, 21 December 2015 (UTC)[reply]
I agree with Natuur12, this is creating a safe feeling, but not real safety. I've had a password of four digits (two numbers and two lettres, one of them was a capital) that was perfectly safe. Dqfn13 (talk) 12:22, 21 December 2015 (UTC)[reply]
2 numbers and 2 (I'm assuming english letters) = 10*10*26*26*2*2 = 270400 possible combinations ≈ 18 bits of entropy. So an attacker would need to make 217 guesses. If we assume 1000 guesses a second [How many guesses an attacker can make a second depends a lot on your attack model.], your password would be cracked in 4.5 minutes. BWolff (WMF) (talk) 11:12, 22 December 2015 (UTC)[reply]
Is it possible though to brute force passwords like that for Wikimedia's accounts? Aren't there any limits on how many failed logins, say, per 30 minutes, are allowed for an account? --Yury Bulka (talk) 11:28, 22 December 2015 (UTC)[reply]
There's two scenario's: - #1: In an offline attack, the attacker manages to somehow compromise the Wikimedia password list, and is only limited by the speed of their computer (We use PBKDF, so the speed of their computer is actually quite slow. My desktop can do about 2 pbkdf hashes per second, but an attacker might have specialized equipment [e.g. GPU based hashers], and should be assumed to be able to crack passwords several orders of magnitude faster.). Obviously, an attacker compromising the password file would be really bad, and will hopefully never happen. But it has happened to other high profile websites (e.g. LinkedIn, Adobe, lastpass), If we prepare for the worst, then we'll still be ok if it ever comes to pass (In particular, compare what happened to LinkedIn or adobe vs lastpass. Lastpass had much better systems in place, and survived the breach much better than adobe or LinkedIn). Scenario #2 is an online attack. This is where the attacker tries to guess passwords by directly logging in. Currently we have two limitations: If there have been 5 failed attempts in less than 5 minutes to login for a specific user from the same IP, then further attempts are prevented until the 5 minutes are up. Additionally, if there are three failed login attempts for any user, all from the same IP, then a CAPTCHA is shown for anyone trying to log in from that IP for the next 5 minutes (Keep in mind, our captchas aren't exactly high quality). However, an attacker might control thousands of IP addresses (e.g. Command a Botnet). Additionally, the online attack is also limited by how fast WMF servers can hash PBKDF (One would hope that would not be the limiting factor in the online scenario) I feel that there's probably a lot we could do to better limit attackers in the online scenario that we aren't doing currently (phab:T122164). Last of all, we do have logging of failed login attempts in place (especially for admins). If someone is making a large number of attempts to log in to an admin account, it would eventually get noticed in the server logs, so they wouldn't be able to keep up doing it for very long. In conclusion, to answer your question - Maybe. Depends on a lot of factors. In the ideal case no they wouldn't, at the very least they would get noticed. But we should plan for things to go wrong. BWolff (WMF) (talk) 13:21, 22 December 2015 (UTC)[reply]
Thanks for the detailed answer. This is good to know, and it also confirms that in a realistic scenario it is more likely that if one wants to really exploit this, they'd rather try to compromise the computer used by an admin and steal their password (how often do admins leave their machines unattended on mass gatherings like Wikimania or local wiki conferences?), or even force the admin to surrender the password, which, unfortunately, is also a risk to consider if we're talking about an admin who lives in some tough country. This is why it can only be solved with some transparent code review process for the sensitive pages. --Yury Bulka (talk) 14:47, 22 December 2015 (UTC)[reply]
Yes, if someone is able to get a keylogger on an admins machine, or in an extreme case, use "rubber-hose" cryptanalysis (euphemism for beating a password out of someone), then its pretty much all over regardless of how secure the password is. However, most attackers over the internet won't have the type of access to beat a password out of someone (One hopes), and that type of attack contains a much higher risk level for the attacker. So in practice, there's still a large class of attacker who would use password guessing (much larger than the the class who would use a more direct approach), as doing a simple repetitive guessing attack is unlikely to have real world consequences, and can be done without physical access to the victim. BWolff (WMF) (talk) 20:46, 22 December 2015 (UTC)[reply]
This measures do not provide security, they just give false sense of security. Eight bytes in UTF-8 encoding is four cyrillic characters. The password "ключ" is not secure in any way. Neither is «𦈘𦈘» (4 bytes per character). And last time I checked, the word "пароль" (password in Russian) was not on RockYou list at all. --Grebenkov (talk) 17:59, 21 December 2015 (UTC)[reply]
Its meant as a minimum standard. Ultimately we can't stop people from doing stupid things. This will hopefully prevent people from doing extremely stupid things and help educate people who don't know better. For non-english passwords - there may be more bytes per letter, but there are also more letters when you include all languages not just english, and those letters are also rarer. So there's an argument to be made that 1 non-latin letter is worth 2 latin letters. But that also depends on if the attacker knows that your password is all Cyrillic. I didn't find very many common password lists that had non-english passwords on them (If you know any, please let me know). Although it might be a good start to add everything listed at d:Q161157#sitelinks-wikipedia. From what I've heard, there's also quite a bit of bias among people who crack passwords, to generally try english passwords instead of other languages, but I don't know how true that is, and I don't have a source. BWolff (WMF) (talk) 11:12, 22 December 2015 (UTC)[reply]
solves a problem not in evidence. need to improve admin passwords. the prescriptive rulemaking is not a solution, rather need to train those with responsibility to practice good security. need to implement better security than passwords, such as encryption. Slowking4 (talk) 19:58, 21 December 2015 (UTC)[reply]
i'm suggesting that we do not know what the state of password practice is; we need training in good practice. see the comments of Guy Macon [1] or Schneier [2] i'm suggesting encryption is a better solution, PGP is possible, for trusted accounts. it is the future, might as well get started. Slowking4 (talk) 16:14, 22 December 2015 (UTC)[reply]
Oppose per Yair rand. It’s a nice try to enforce responsibility on the parties involved, but as noted above by the proposer himself, we can’t stop people from doing stupid things.
We can, of course, pretend that we’ve stopped some of them doing some of these things, but it has more to do with our perception than with security itself.
Per Vogone, if we trust users to use these rights sensibly, then we can trust them to have a secure password. Using bytes to determine the security of a password simply makes no sense. Password security is more complex than simply string length. Caliburn (talk) 17:39, 22 December 2015 (UTC)[reply]
First, passwords are not reliable anymore. Any script kid now has tens or hundreds of millions of passwords they can check in no time. Imposing a longer password will only give a false sense of security. If we are truly worried about security, we should consider 2-factor authentication or similar.
Secondly, while one can do a lot from MediaWiki:Common.js, this is generally a well-followed page and changes to it do not go unnoticed. Therefore I don't see the need to impose additional requirements to users who can edit that file.--Strainu (talk) 18:10, 22 December 2015 (UTC)[reply]
We use PBKDF to make password checking take time. But ultimately that's why complex passwords are important. A good password will take a lot more than a million tries to guess. As for JS. Depending on the attack, the attacker might only need to control that page for a very short time. The attacker can also insert code to make sure his/her changes don't show up on the usual lists. Also, MediaWiki:Common.js is the most well known js page, its hardly the only one. There are other pages in MW namespace that allow javascript injection, many of which are rather obscure. BWolff (WMF) (talk) 20:52, 22 December 2015 (UTC)[reply]
Are we talking about PBKDF as in RFC 2898 ? I'm not very familiar with it, how much time does it actually take to check 100M passwords with that, compared to a simple hash? But my point was the limitations you're planning to introduce are useless if the users already used the same (complicated) password in other websites that were compromised and their password is now freely available on the internet, along with their associated username and/or email address.--Strainu (talk) 15:09, 24 December 2015 (UTC)[reply]
I don't see any permissions of admins that would justify elevated security measures; anything admins can do, can easily be reverted by any other admin. So I doubt the necessity of such a change of policy. OTOH so far I used a pretty weak password here, as I initially gave WP a pretty low security level. So I just changed it to a somewhat higher, but still modest level. --h-stt!?09:49, 23 December 2015 (UTC)[reply]
Oppose - It'll take until well beyond the heat death of the universe to crack my password by brute-forcing it while offline. If we consider that as insecure, how is the two-factor authentication any better? This is only a pretense of security, because, if the password can somehow be compromised despite this, it will require someone either (1) breaking into my machine and RAT-ing it, or (2) breaking into the WMF's servers and accessing the database directly. Both get around the need for a password or 2FA in the first place. Reaper Eternal (talk) 15:36, 23 December 2015 (UTC)[reply]
Umm, there is no password that both fails to meet the proposed requirements, and would take longer than the heat death of the universe to crack in an offline attack. So I'm not sure why this is an argument to oppose the minimum password strength requirements. If your password is really that secure, it is above and beyond the requirements being proposed here. BWolff (WMF) (talk) 00:14, 24 December 2015 (UTC)[reply]
