Since Friday, we've had a slow but steady stream of admin account compromises on WMF projects. The hacker group OurMine has taken credit for these compromises.
We're fairly sure now that their mode of operation involves searching for target admins in previous user/password dumps published by other hackers, such as the 2013 Adobe hack. They're not doing an online brute force attack against WMF. For each target, they try one or two passwords, and if those don't work, they go on to the next target. Their success rate is maybe 10%.
When they compromise an account, they usually do a main page defacement or similar, get blocked, and then move on to the next target.
Today, they compromised the account of a www.mediawiki.org admin, did a main page defacement there, and then (presumably) used the same password to log in to Gerrit. They took a screenshot, sent it to us, but took no other action.
So, I don't think they are truly malicious -- I think they are doing it for fun, fame, perhaps also for their stated goal of bringing attention to poor password security.
Indications are that they are familiarising themselves with MediaWiki and with our community. They probably plan on continuing to do this for some time.
We're doing what we can to slow them down, but admins and other users with privileged access also need to take some responsibility for the security of their accounts. Specifically:
* If you're an admin, please enable two-factor authentication. https://meta.wikimedia.org/wiki/H:2FA * Please change your password, if you haven't already changed it in the last week. Use a new password that is not used on any other site. * Please do not share passwords across different WMF services, for example, between the wikis and Gerrit.
(Cross-posted to wikitech-l and wikimedia-l, please copy/link elsewhere as appropriate.)
-- Tim Starling
By the way, it seems that the password change form doesn't provide feedback on password strength. Also a link to resource to learn how to chose strong password, like this https://en.wikibooks.org/wiki/Information_Security_in_Education/Authentication#Username.2FPassword_Combinations_for_Identification_.26_Authentication, that https://en.wikibooks.org/wiki/The_Computer_Revolution/Security/Passwords, or something else https://en.wikibooks.org/wiki/Using_Wikibooks/Setting_Up_A_User_Account#Choosing_a_Good_Password.
Safely, mathieu
Le 16/11/2016 à 10:57, Tim Starling a écrit :
Since Friday, we've had a slow but steady stream of admin account compromises on WMF projects. The hacker group OurMine has taken credit for these compromises.
We're fairly sure now that their mode of operation involves searching for target admins in previous user/password dumps published by other hackers, such as the 2013 Adobe hack. They're not doing an online brute force attack against WMF. For each target, they try one or two passwords, and if those don't work, they go on to the next target. Their success rate is maybe 10%.
When they compromise an account, they usually do a main page defacement or similar, get blocked, and then move on to the next target.
Today, they compromised the account of a www.mediawiki.org admin, did a main page defacement there, and then (presumably) used the same password to log in to Gerrit. They took a screenshot, sent it to us, but took no other action.
So, I don't think they are truly malicious -- I think they are doing it for fun, fame, perhaps also for their stated goal of bringing attention to poor password security.
Indications are that they are familiarising themselves with MediaWiki and with our community. They probably plan on continuing to do this for some time.
We're doing what we can to slow them down, but admins and other users with privileged access also need to take some responsibility for the security of their accounts. Specifically:
- If you're an admin, please enable two-factor authentication.
https://meta.wikimedia.org/wiki/H:2FA
- Please change your password, if you haven't already changed it in
the last week. Use a new password that is not used on any other site.
- Please do not share passwords across different WMF services, for
example, between the wikis and Gerrit.
(Cross-posted to wikitech-l and wikimedia-l, please copy/link elsewhere as appropriate.)
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, 2016-11-16 at 11:14 +0100, mathieu stumpf guntz wrote:
By the way, it seems that the password change form doesn't provide feedback on password strength.
See https://phabricator.wikimedia.org/T32574#1924603
andre
On 16/11/16 10:14, mathieu stumpf guntz wrote:
By the way, it seems that the password change form doesn't provide feedback on password strength. Also a link to resource to learn how to chose strong password, like this https://en.wikibooks.org/wiki/Information_Security_in_Education/Authentication#Username.2FPassword_Combinations_for_Identification_.26_Authentication, that https://en.wikibooks.org/wiki/The_Computer_Revolution/Security/Passwords, or something else https://en.wikibooks.org/wiki/Using_Wikibooks/Setting_Up_A_User_Account#Choosing_a_Good_Password.
Safely, mathieu
I would be good to run a password strength checker at login time as well, as the software should, for a brief moment, have a copy of the plaintext password that can be scanned, before it hashes it for checking and forgets the plaintext.
Users with weak passwords, or passwords which are on an existing crack list, can then be warned at login time that they have a weak password, and prompted to change it.
Neil
On 16/11/16 13:56, Neil Harris wrote:
On 16/11/16 10:14, mathieu stumpf guntz wrote:
By the way, it seems that the password change form doesn't provide feedback on password strength. Also a link to resource to learn how to chose strong password, like this https://en.wikibooks.org/wiki/Information_Security_in_Education/Authentication#Username.2FPassword_Combinations_for_Identification_.26_Authentication, that https://en.wikibooks.org/wiki/The_Computer_Revolution/Security/Passwords, or something else https://en.wikibooks.org/wiki/Using_Wikibooks/Setting_Up_A_User_Account#Choosing_a_Good_Password.
Safely, mathieu
I would be good to run a password strength checker at login time as well, as the software should, for a brief moment, have a copy of the plaintext password that can be scanned, before it hashes it for checking and forgets the plaintext.
Users with weak passwords, or passwords which are on an existing crack list, can then be warned at login time that they have a weak password, and prompted to change it.
Neil
Another idea might be to for the software to offer to create a random password for users at account creation time, and also to make the same offer at password change time.
For example, even using automatically generated simple-looking and reasonably simple passwords like "little-center-ground-finger" consisting of 4 words between 5 and 8 characters long, will give an effective per-password entropy of 62 bits, significantly better than most user-generated passwords.
Neil
2016-11-16 22:11 GMT+08:00 Neil Harris neil@tonal.clara.co.uk:
For example, even using automatically generated simple-looking and reasonably simple passwords like "little-center-ground-finger" consisting of 4 words between 5 and 8 characters long, will give an effective per-password entropy of 62 bits, significantly better than most user-generated passwords.
You mean https://www.xkcd.com/936/ ? :)
On 16/11/16 15:08, YiFei wrote:
2016-11-16 22:11 GMT+08:00 Neil Harris neil@tonal.clara.co.uk:
For example, even using automatically generated simple-looking and reasonably simple passwords like "little-center-ground-finger" consisting of 4 words between 5 and 8 characters long, will give an effective per-password entropy of 62 bits, significantly better than most user-generated passwords.
You mean https://www.xkcd.com/936/ ? :)
I mean exactly that.
Neil
Another idea might be to for the software to offer to create a random password for users at account creation time, and also to make the same offer at password change time.
For example, even using automatically generated simple-looking and reasonably simple passwords like "little-center-ground-finger" consisting of 4 words between 5 and 8 characters long, will give an effective per-password entropy of 62 bits, significantly better than most user-generated passwords.
Neil
If we did this it's worth pro-actively making the wordlist "hard". For example, the words chosen above appear in the top-1000 most common English words, and so therefore are trivially vulnerable to dictionary attacks (hackers read XKCD too :)).
On Wed, Nov 16, 2016 at 3:19 PM, Thomas Morton <morton.thomas@googlemail.com
wrote:
Another idea might be to for the software to offer to create a random password for users at account creation time, and also to make the same offer at password change time.
For example, even using automatically generated simple-looking and reasonably simple passwords like "little-center-ground-finger" consisting of 4 words between 5 and 8 characters long, will give an effective per-password entropy of 62 bits, significantly better than most user-generated passwords.
If we did this it's worth pro-actively making the wordlist "hard". For example, the words chosen above appear in the top-1000 most common English words, and so therefore are trivially vulnerable to dictionary attacks (hackers read XKCD too :)).
If you use the top-1000 most common English words (and the attacker knows you picked 4 random words from that list), 4 randomly-chosen words would have about 39.86 bits of entropy. That's a bit weak, but probably not entirely trivial (at 1000 guesses/second it'd take 31 years to try all the possibilities). Using a list of 1000 *un*common English words has the same level of entropy, since we assume the attacker can get the word list somehow (if nothing else, by using the service themselves a few thousand times and collecting all the words seen).
If you want to increase the entropy, use a larger word list rather than a "harder" one. The XKCD comic seems to have used a 2048-word list for its 44-bit estimate. Using a list with 8836 words gets the same entropy (about 52.44 bits) as a completely-random 8-character password using any of the 94 characters I can easily type on my keyboard (e.g. "'>hZ|=S*").
Well, I didn't mistyped my password lately, but probably we have a limit of successive attempt to connexion failure, haven't we? So even relatively weak password are a far less big deal, the problem seemed to be that many password where know from attackers due to external leak.
Le 16/11/2016 à 22:41, Brad Jorsch (Anomie) a écrit :
On Wed, Nov 16, 2016 at 3:19 PM, Thomas Morton <morton.thomas@googlemail.com
wrote:
Another idea might be to for the software to offer to create a random password for users at account creation time, and also to make the same offer at password change time.
For example, even using automatically generated simple-looking and reasonably simple passwords like "little-center-ground-finger" consisting of 4 words between 5 and 8 characters long, will give an effective per-password entropy of 62 bits, significantly better than most user-generated passwords.
If we did this it's worth pro-actively making the wordlist "hard". For example, the words chosen above appear in the top-1000 most common English words, and so therefore are trivially vulnerable to dictionary attacks (hackers read XKCD too :)).
If you use the top-1000 most common English words (and the attacker knows you picked 4 random words from that list), 4 randomly-chosen words would have about 39.86 bits of entropy. That's a bit weak, but probably not entirely trivial (at 1000 guesses/second it'd take 31 years to try all the possibilities). Using a list of 1000 *un*common English words has the same level of entropy, since we assume the attacker can get the word list somehow (if nothing else, by using the service themselves a few thousand times and collecting all the words seen).
If you want to increase the entropy, use a larger word list rather than a "harder" one. The XKCD comic seems to have used a 2048-word list for its 44-bit estimate. Using a list with 8836 words gets the same entropy (about 52.44 bits) as a completely-random 8-character password using any of the 94 characters I can easily type on my keyboard (e.g. "'>hZ|=S*").
If you want to increase the entropy, use a larger word list rather than a "harder" one. The XKCD comic seems to have used a 2048-word list for its 44-bit estimate. Using a list with 8836 words gets the same entropy (about 52.44 bits) as a completely-random 8-character password using any of the 94 characters I can easily type on my keyboard (e.g. "'>hZ|=S*").
If we want to go this way, we have the largest conceivable word list at hand with the Wiktionary.
A tool inspired by https://tools.wmflabs.org/anagrimes/hasard.php?langue=en could give 4 words from all those we have in English, and we can even get words in the same language as the registration form (So it would suggest French words when registering on the French Wikipedia, Swedish words on the Swedish Wikisource, etc.
Sylvain
On Thu, Nov 17, 2016 at 1:19 PM, Sylvain Boissel < sylvain.boissel@wikimedia.fr> wrote:
If you want to increase the entropy, use a larger word list rather than a "harder" one. The XKCD comic seems to have used a 2048-word list for its 44-bit estimate. Using a list with 8836 words gets the same entropy
(about
52.44 bits) as a completely-random 8-character password using any of the
94
characters I can easily type on my keyboard (e.g. "'>hZ|=S*").
If we want to go this way, we have the largest conceivable word list at hand with the Wiktionary.
A tool inspired by https://tools.wmflabs.org/ anagrimes/hasard.php?langue=en could give 4 words from all those we have in English, and we can even get words in the same language as the registration form (So it would suggest French words when registering on the French Wikipedia, Swedish words on the Swedish Wikisource, etc.
You want to go with relatively frequent words of reasonable length so the combination is reasonably memorable and easy enough to type, or you are back to random gibberish strings.
While not likely, choosing four random English words from Wiktionary *could *give you this combo
aavakaayaabaciscusesæolotropicpneumonoultramicroscopicsilicovolcanoconiosis
Trey Jones Software Engineer, Discovery Wikimedia Foundation
A button to suggest another combo would help in this case (and anyway, we should not force the user to use the suggested password.)
I tried a couple times, I got this: YMCKO-jackpotting-mental disorder-hulk BCMS-Myspace angle-colloquium-charley horse extendible-milkiness-contemplate-marron
While I don't know all of these words (English is not my first language), it does look usable.
Sylvain
2016-11-17 19:32 GMT+01:00 Trey Jones tjones@wikimedia.org:
On Thu, Nov 17, 2016 at 1:19 PM, Sylvain Boissel < sylvain.boissel@wikimedia.fr> wrote:
If you want to increase the entropy, use a larger word list rather
than a
"harder" one. The XKCD comic seems to have used a 2048-word list for
its
44-bit estimate. Using a list with 8836 words gets the same entropy
(about
52.44 bits) as a completely-random 8-character password using any of
the
94
characters I can easily type on my keyboard (e.g. "'>hZ|=S*").
If we want to go this way, we have the largest conceivable word list at hand with the Wiktionary.
A tool inspired by https://tools.wmflabs.org/ anagrimes/hasard.php?langue=en could give 4 words from all those we have in English, and we can even get words in the same language as the registration form (So it would suggest French words when registering on the French Wikipedia, Swedish words on
the
Swedish Wikisource, etc.
You want to go with relatively frequent words of reasonable length so the combination is reasonably memorable and easy enough to type, or you are back to random gibberish strings.
While not likely, choosing four random English words from Wiktionary *could *give you this combo
aavakaayaabaciscusesæolotropicpneumonoultramicroscopicsilico volcanoconiosis
Trey Jones Software Engineer, Discovery Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi!
I would be good to run a password strength checker at login time as well, as the software should, for a brief moment, have a copy of the plaintext password that can be scanned, before it hashes it for checking and forgets the plaintext.
Another measure may be to have a bot that scans the accounts periodically (maybe for starters only on admin, etc. high privilege accounts) and alerts on weakly-passworded ones? We know bad (or at least greyhat) guys do that, so maybe to prevent it we should try using the same approach?
2FA would be a big prevention of these problems.
Allowing accounts to be handled through 3rd party services, such as a Github, would also prevent it. Github already has 2FA available for logins.
On Wed, Nov 16, 2016 at 10:26 AM, Stas Malyshev smalyshev@wikimedia.org wrote:
Hi!
I would be good to run a password strength checker at login time as well, as the software should, for a brief moment, have a copy of the plaintext password that can be scanned, before it hashes it for checking and forgets the plaintext.
Another measure may be to have a bot that scans the accounts periodically (maybe for starters only on admin, etc. high privilege accounts) and alerts on weakly-passworded ones? We know bad (or at least greyhat) guys do that, so maybe to prevent it we should try using the same approach?
-- Stas Malyshev smalyshev@wikimedia.org
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Nov 16, 2016 at 8:30 AM Cyken Zeraux cykenzeraux@gmail.com wrote:
2FA would be a big prevention of these problems.
Allowing accounts to be handled through 3rd party services, such as a Github, would also prevent it. Github already has 2FA available for logins.
Relying on Github prevents nothing if you don't use 2FA or a unique password ;-)
Really, the single best thing one can do to prevent this from happening is using unique passwords. This is best practice for *any* website you have access to, not just Wikimedia.
Enabling 2FA on websites that provide it is the next step everyone should take, if and when they can.
-Chad
At the very least if 2FA is not possible for you;
# sign up for the have I been pwned website so you get alerts when your passwords may have been compromised # use a password manager like 1password so that you can use long unique passwords for each site
T
On Wed, 16 Nov 2016 16:39 Chad, innocentkiller@gmail.com wrote:
On Wed, Nov 16, 2016 at 8:30 AM Cyken Zeraux cykenzeraux@gmail.com wrote:
2FA would be a big prevention of these problems.
Allowing accounts to be handled through 3rd party services, such as a Github, would also prevent it. Github already has 2FA available for
logins.
Relying on Github prevents nothing if you don't use 2FA or a unique password ;-)
Really, the single best thing one can do to prevent this from happening is using unique passwords. This is best practice for *any* website you have access to, not just Wikimedia.
Enabling 2FA on websites that provide it is the next step everyone should take, if and when they can.
-Chad _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Some thoughts:
Likely users with sysop/cu/os etc. access should be forked to change the password, if the password hasn't been changed for long time?
And we have to remember that admins can do moor then just editing the mainpage or protecting pages, thus it is important to remember users to change the password or to use two factor auth.
--Steinsplitter
________________________________ Von: Wikitech-l wikitech-l-bounces@lists.wikimedia.org im Auftrag von Tim Starling tstarling@wikimedia.org Gesendet: Mittwoch, 16. November 2016 10:57 An: wikitech-l@lists.wikimedia.org Cc: wikimedia-l@lists.wikimedia.org Betreff: [Wikitech-l] Update on WMF account compromises
Since Friday, we've had a slow but steady stream of admin account compromises on WMF projects. The hacker group OurMine has taken credit for these compromises.
We're fairly sure now that their mode of operation involves searching for target admins in previous user/password dumps published by other hackers, such as the 2013 Adobe hack. They're not doing an online brute force attack against WMF. For each target, they try one or two passwords, and if those don't work, they go on to the next target. Their success rate is maybe 10%.
When they compromise an account, they usually do a main page defacement or similar, get blocked, and then move on to the next target.
Today, they compromised the account of a www.mediawiki.orghttp://www.mediawiki.org admin, did a main page defacement there, and then (presumably) used the same password to log in to Gerrit. They took a screenshot, sent it to us, but took no other action.
So, I don't think they are truly malicious -- I think they are doing it for fun, fame, perhaps also for their stated goal of bringing attention to poor password security.
Indications are that they are familiarising themselves with MediaWiki and with our community. They probably plan on continuing to do this for some time.
We're doing what we can to slow them down, but admins and other users with privileged access also need to take some responsibility for the security of their accounts. Specifically:
* If you're an admin, please enable two-factor authentication. https://meta.wikimedia.org/wiki/H:2FA * Please change your password, if you haven't already changed it in the last week. Use a new password that is not used on any other site. * Please do not share passwords across different WMF services, for example, between the wikis and Gerrit.
(Cross-posted to wikitech-l and wikimedia-l, please copy/link elsewhere as appropriate.)
-- Tim Starling
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hello, Am 16.11.2016 um 16:49 schrieb Steinsplitter Wiki:
should be forked to change the password, if the password hasn't been changed for long time?
if you mean: now, for 1 time: yes (the problem is that there is no databank-field that stores the change-date AFAIR).
if you mean: periodically: no. Because it is generally not a good idea to force users to switch passwords or make too strong rules for passwords. The reason is simple: The users will become creative to circumvent it (they are not creative for strong passwords, but for this). They will write their passwords down, create silly but long passwords, use a pattern (like adding the month to a small password) and so on.
Sincerely, DaB.
In addition to the suggestions from Tim:
(0) Consider testing your password strength with a tool like http://www.testyourpassword.com/; be sure that the tool you use does not send your chosen password over the Internet and instead tests it locally.
(1) If you find it difficult to remember strong passwords then consider using a password manager https://en.wikipedia.org/wiki/Password_manager.
(2) As a variation on the suggestions above, please *do not* use the same password, or a similar password, for your email account that you use for your Wikimedia password. This applies both to WMF email accounts and community email accounts.
(3) Also consider changing, testing, and upgrading your passwords for your bot accounts.
(4) Also consider changing, testing, and upgrading your passwords for your IRC accounts.
Pine
On Wed, Nov 16, 2016 at 1:57 AM, Tim Starling tstarling@wikimedia.org wrote:
Since Friday, we've had a slow but steady stream of admin account compromises on WMF projects. The hacker group OurMine has taken credit for these compromises.
We're fairly sure now that their mode of operation involves searching for target admins in previous user/password dumps published by other hackers, such as the 2013 Adobe hack. They're not doing an online brute force attack against WMF. For each target, they try one or two passwords, and if those don't work, they go on to the next target. Their success rate is maybe 10%.
When they compromise an account, they usually do a main page defacement or similar, get blocked, and then move on to the next target.
Today, they compromised the account of a www.mediawiki.org admin, did a main page defacement there, and then (presumably) used the same password to log in to Gerrit. They took a screenshot, sent it to us, but took no other action.
So, I don't think they are truly malicious -- I think they are doing it for fun, fame, perhaps also for their stated goal of bringing attention to poor password security.
Indications are that they are familiarising themselves with MediaWiki and with our community. They probably plan on continuing to do this for some time.
We're doing what we can to slow them down, but admins and other users with privileged access also need to take some responsibility for the security of their accounts. Specifically:
- If you're an admin, please enable two-factor authentication.
https://meta.wikimedia.org/wiki/H:2FA
- Please change your password, if you haven't already changed it in
the last week. Use a new password that is not used on any other site.
- Please do not share passwords across different WMF services, for
example, between the wikis and Gerrit.
(Cross-posted to wikitech-l and wikimedia-l, please copy/link elsewhere as appropriate.)
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Nov 16, 2016 at 1:19 PM, Pine W wiki.pine@gmail.com wrote:
(1) If you find it difficult to remember strong passwords then consider using a password manager https://en.wikipedia.org/wiki/Password_manager.
For Unix/GPG types, I can recommend http://www.passwordstore.org/ -- `aptitude install pass`.
It's very old-school cool. --scott
Le 16/11/2016 à 19:19, Pine W a écrit :
(0) Consider testing your password strength with a tool like http://www.testyourpassword.com/; be sure that the tool you use does not send your chosen password over the Internet and instead tests it locally.
By using an online testing tool, you are effectively breaking the very first rule:
DO NOT GIVE OUT YOUR PASSWORD. EVER.
Using that site is exactly like sharing your password with a random stranger in the world. Even if you trusted that website, and audited the code at a given point in time, you have no guarantee the site hasn't changed or that it is not collecting passwords.
On Thu, Nov 17, 2016 at 12:18 AM Antoine Musso hashar+wmf@free.fr wrote:
Le 16/11/2016 à 19:19, Pine W a écrit :
(0) Consider testing your password strength with a tool like http://www.testyourpassword.com/; be sure that the tool you use does not send your chosen password over the Internet and instead tests it locally.
By using an online testing tool, you are effectively breaking the very first rule:
DO NOT GIVE OUT YOUR PASSWORD. EVER.
Using that site is exactly like sharing your password with a random stranger in the world. Even if you trusted that website, and audited the code at a given point in time, you have no guarantee the site hasn't changed or that it is not collecting passwords.
Not to mention, it's plain-old-insecure HTTP, so of course anyone and their mother's uncle could be sniffing the traffic ;-)
Same rule goes for a "generate a random password" site. Don't use them.
-Chad
So are you telling me that tool "test if your credit card was cloned" is a fraud? But its test included my ccv2 too! :p
Vito
2016-11-17 9:33 GMT+01:00 Chad innocentkiller@gmail.com:
On Thu, Nov 17, 2016 at 12:18 AM Antoine Musso hashar+wmf@free.fr wrote:
Le 16/11/2016 à 19:19, Pine W a écrit :
(0) Consider testing your password strength with a tool like http://www.testyourpassword.com/; be sure that the tool you use does
not
send your chosen password over the Internet and instead tests it
locally.
By using an online testing tool, you are effectively breaking the very first rule:
DO NOT GIVE OUT YOUR PASSWORD. EVER.
Using that site is exactly like sharing your password with a random stranger in the world. Even if you trusted that website, and audited the code at a given point in time, you have no guarantee the site hasn't changed or that it is not collecting passwords.
Not to mention, it's plain-old-insecure HTTP, so of course anyone and their mother's uncle could be sniffing the traffic ;-)
Same rule goes for a "generate a random password" site. Don't use them.
-Chad _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi!
By using an online testing tool, you are effectively breaking the very first rule:
DO NOT GIVE OUT YOUR PASSWORD. EVER.
That's why I suggested having internal bot that would use the same techniques intruders use to test passwords (without knowing them), instead of having people to send their pwds to unknown site and trust them not to do anything wrong with it :)
I'm not sure that I agree with that assessment *of password strength testing tools* (not humans), for a couple of reasons.
0. Weak passwords are a huge problem, and may be closely related to the weakness that the attackers are currently using to compromise Wikimedia accounts. As far as I know, Wikimedia currently has no internal way to deal with that problem. We *should* have a way to deal with that problem, but it seems to me that using a tool that I recommended is the lesser of two evils at the moment. In the long run, it would be much better if Wikimedia had an internal tool to validate the strength of users' passwords and block passwords that fall below a certain strength level.
1. If you don't trust that strength testing site (which is fine), choose another. I did a couple of quick checks on that site; while it's entirely possible that I missed something, it appeared to me that the site was not sending passwords over the Internet, whether in the clear or encrypted. The use of HTTP or HTTPS is irrelevant if the data isn't getting sent out in the first place.
Do you have a better solution in mind to deal with the immediate problem of weak passwords, besides 2FA which is not available to everyone?
Pine
On Thu, Nov 17, 2016 at 12:08 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 16/11/2016 à 19:19, Pine W a écrit :
(0) Consider testing your password strength with a tool like http://www.testyourpassword.com/; be sure that the tool you use does not send your chosen password over the Internet and instead tests it locally.
By using an online testing tool, you are effectively breaking the very first rule:
DO NOT GIVE OUT YOUR PASSWORD. EVER.
Using that site is exactly like sharing your password with a random stranger in the world. Even if you trusted that website, and audited the code at a given point in time, you have no guarantee the site hasn't changed or that it is not collecting passwords.
-- Antoine "hashar" Musso
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 2016-11-17 9:28 AM, Pine W wrote:
- If you don't trust that strength testing site (which is fine), choose
another. I did a couple of quick checks on that site; while it's entirely possible that I missed something, it appeared to me that the site was not sending passwords over the Internet, whether in the clear or encrypted. The use of HTTP or HTTPS is irrelevant if the data isn't getting sent out in the first place.
Using HTTP means that a man in the middle could inject a script into these sites that would extract any password entered into them.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2016-11-17 9:28 AM, Pine W wrote:
- If you don't trust that strength testing site (which is fine), choose
another. I did a couple of quick checks on that site; while it's entirely possible that I missed something, it appeared to me that the site was not sending passwords over the Internet, whether in the clear or encrypted. The use of HTTP or HTTPS is irrelevant if the data isn't getting sent out in the first place.
Using HTTP means that a man in the middle could inject a script into these sites that would extract any password entered into them.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On Thu, Nov 17, 2016 at 12:28 PM, Pine W wiki.pine@gmail.com wrote:
- If you don't trust that strength testing site (which is fine), choose
another. I did a couple of quick checks on that site; while it's entirely possible that I missed something, it appeared to me that the site was not sending passwords over the Internet, whether in the clear or encrypted. The use of HTTP or HTTPS is irrelevant if the data isn't getting sent out in the first place.
Or use a password manager that has a local built-in password strength tool, that way you don't risk being MiTMed by an HTTP site.
In general, as mentioned, you should simply not enter your password on any website that is not the site the password belongs to. For my full-time job, employees have a Chrome extension where accidentally type your password on any website (even if it's not in a text box) you're required to reset it.
*-- * Regards,
*Tyler Romeo* 0x405d34a7c86b42df https://parent5446.nyc
Good point about MITM doing script injection, which I hadn't fully considered. I'm not sure that going to HTTPS would solve everything (e.g. that alone wouldn't prevent the origin site from reading passwords that someone enters into the tool, and HTTPS is not foolproof) but it would indeed be a big step in the right direction to avoid MITM.
I wonder (looking at the WMF people in the room) how quickly could WMF deploy a password strength checking tool to the Wikimedia sites? That won't solve all of the problems but it would be a step in the right direction.
Pine
On Thu, Nov 17, 2016 at 10:00 AM, Tyler Romeo tylerromeo@gmail.com wrote:
On Thu, Nov 17, 2016 at 12:28 PM, Pine W wiki.pine@gmail.com wrote:
- If you don't trust that strength testing site (which is fine), choose
another. I did a couple of quick checks on that site; while it's entirely possible that I missed something, it appeared to me that the site was not sending passwords over the Internet, whether in the clear or encrypted.
The
use of HTTP or HTTPS is irrelevant if the data isn't getting sent out in the first place.
Or use a password manager that has a local built-in password strength tool, that way you don't risk being MiTMed by an HTTP site.
In general, as mentioned, you should simply not enter your password on any website that is not the site the password belongs to. For my full-time job, employees have a Chrome extension where accidentally type your password on any website (even if it's not in a text box) you're required to reset it.
*-- * Regards,
*Tyler Romeo* 0x405d34a7c86b42df https://parent5446.nyc _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Tyler wrote:
In general, as mentioned, you should simply not enter your password on any website that is not the site the password belongs to. For my full-time
job,
employees have a Chrome extension where accidentally type your password on any website (even if it's not in a text box) you're required to reset it.
[Slightly off topic] That is an interesting approach. Obviously not applicable to us, but in a corporate setting I imagine it could be quite effective.
One thing I would worry about is the potential for timing attacks as you are now doing password comparisons against untrusted input from all over the internet with no rate limitting. I suppose that is taken into account when writing the extension though and precautions are taken.
-- bawolff
Hello
I had the super bad idea of implementing the two-factor authentication and now I need help :)
The system is not "recording" me as registered. Which means that I am disconnected every once in a while. Roughly every 15 minutes... and every time I change project (from Wikipedia to Commons etc.)
Which means that every 15 minutes, I need to relogin... retype login and password... grab my phone... wake it up... launch the app... get the number... enter it... validate... OK, good to go for 15 minutes...
So... how do I fix that ?
Thanks
Florence
Le 16/11/2016 à 10:57, Tim Starling a écrit :
Since Friday, we've had a slow but steady stream of admin account compromises on WMF projects. The hacker group OurMine has taken credit for these compromises.
We're fairly sure now that their mode of operation involves searching for target admins in previous user/password dumps published by other hackers, such as the 2013 Adobe hack. They're not doing an online brute force attack against WMF. For each target, they try one or two passwords, and if those don't work, they go on to the next target. Their success rate is maybe 10%.
When they compromise an account, they usually do a main page defacement or similar, get blocked, and then move on to the next target.
Today, they compromised the account of a www.mediawiki.org admin, did a main page defacement there, and then (presumably) used the same password to log in to Gerrit. They took a screenshot, sent it to us, but took no other action.
So, I don't think they are truly malicious -- I think they are doing it for fun, fame, perhaps also for their stated goal of bringing attention to poor password security.
Indications are that they are familiarising themselves with MediaWiki and with our community. They probably plan on continuing to do this for some time.
We're doing what we can to slow them down, but admins and other users with privileged access also need to take some responsibility for the security of their accounts. Specifically:
- If you're an admin, please enable two-factor authentication.
https://meta.wikimedia.org/wiki/H:2FA
- Please change your password, if you haven't already changed it in
the last week. Use a new password that is not used on any other site.
- Please do not share passwords across different WMF services, for
example, between the wikis and Gerrit.
(Cross-posted to wikitech-l and wikimedia-l, please copy/link elsewhere as appropriate.)
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Ya, this is why I haven't done it.
Also, I should be able to set it up such that TFA is not necessary until my account attempts to do an admin action.
On Mon, Nov 21, 2016 at 4:37 PM, Florence Devouard fdevouard@gmail.com wrote:
Hello
I had the super bad idea of implementing the two-factor authentication and now I need help :)
The system is not "recording" me as registered. Which means that I am disconnected every once in a while. Roughly every 15 minutes... and every time I change project (from Wikipedia to Commons etc.)
Which means that every 15 minutes, I need to relogin... retype login and password... grab my phone... wake it up... launch the app... get the number... enter it... validate... OK, good to go for 15 minutes...
So... how do I fix that ?
Thanks
Florence
Le 16/11/2016 à 10:57, Tim Starling a écrit :
Since Friday, we've had a slow but steady stream of admin account compromises on WMF projects. The hacker group OurMine has taken credit for these compromises.
We're fairly sure now that their mode of operation involves searching for target admins in previous user/password dumps published by other hackers, such as the 2013 Adobe hack. They're not doing an online brute force attack against WMF. For each target, they try one or two passwords, and if those don't work, they go on to the next target. Their success rate is maybe 10%.
When they compromise an account, they usually do a main page defacement or similar, get blocked, and then move on to the next target.
Today, they compromised the account of a www.mediawiki.org admin, did a main page defacement there, and then (presumably) used the same password to log in to Gerrit. They took a screenshot, sent it to us, but took no other action.
So, I don't think they are truly malicious -- I think they are doing it for fun, fame, perhaps also for their stated goal of bringing attention to poor password security.
Indications are that they are familiarising themselves with MediaWiki and with our community. They probably plan on continuing to do this for some time.
We're doing what we can to slow them down, but admins and other users with privileged access also need to take some responsibility for the security of their accounts. Specifically:
- If you're an admin, please enable two-factor authentication.
https://meta.wikimedia.org/wiki/H:2FA
- Please change your password, if you haven't already changed it in
the last week. Use a new password that is not used on any other site.
- Please do not share passwords across different WMF services, for
example, between the wikis and Gerrit.
(Cross-posted to wikitech-l and wikimedia-l, please copy/link elsewhere as appropriate.)
-- Tim Starling
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
Ya, well I was a good girl and I did as I was told to do.
Now... I changed my password to a VERY simple one so that it takes less time to relogin each time.
And most of my edits are anonymous... which creates a problem to me because I keep being asked to fill up the captcha thing and of course I miss all the nice user features... but it also creates a problem to my peers who have to keep a watch on my anonymous edits.
So, I do not know what is the extent of the current security issue, but I tell you that from a user perspective, the 2 factor authentification system is absolutely not ok :)
I do not know how many people switched and I dunno if all meet the same problem than I.
If others are facing the same consequences... I believe you should stop to push people to implement the 2 steps.
If I am alone in this situation.... please someone remove the 2 factors identification system from my account. Please. Please.
Anthere
Le 21/11/2016 à 11:15, John Mark Vandenberg a écrit :
Ya, this is why I haven't done it.
Also, I should be able to set it up such that TFA is not necessary until my account attempts to do an admin action.
On Mon, Nov 21, 2016 at 4:37 PM, Florence Devouard fdevouard@gmail.com wrote:
Hello
I had the super bad idea of implementing the two-factor authentication and now I need help :)
The system is not "recording" me as registered. Which means that I am disconnected every once in a while. Roughly every 15 minutes... and every time I change project (from Wikipedia to Commons etc.)
Which means that every 15 minutes, I need to relogin... retype login and password... grab my phone... wake it up... launch the app... get the number... enter it... validate... OK, good to go for 15 minutes...
So... how do I fix that ?
Thanks
Florence
Le 16/11/2016 à 10:57, Tim Starling a écrit :
Since Friday, we've had a slow but steady stream of admin account compromises on WMF projects. The hacker group OurMine has taken credit for these compromises.
We're fairly sure now that their mode of operation involves searching for target admins in previous user/password dumps published by other hackers, such as the 2013 Adobe hack. They're not doing an online brute force attack against WMF. For each target, they try one or two passwords, and if those don't work, they go on to the next target. Their success rate is maybe 10%.
When they compromise an account, they usually do a main page defacement or similar, get blocked, and then move on to the next target.
Today, they compromised the account of a www.mediawiki.org admin, did a main page defacement there, and then (presumably) used the same password to log in to Gerrit. They took a screenshot, sent it to us, but took no other action.
So, I don't think they are truly malicious -- I think they are doing it for fun, fame, perhaps also for their stated goal of bringing attention to poor password security.
Indications are that they are familiarising themselves with MediaWiki and with our community. They probably plan on continuing to do this for some time.
We're doing what we can to slow them down, but admins and other users with privileged access also need to take some responsibility for the security of their accounts. Specifically:
- If you're an admin, please enable two-factor authentication.
https://meta.wikimedia.org/wiki/H:2FA
- Please change your password, if you haven't already changed it in
the last week. Use a new password that is not used on any other site.
- Please do not share passwords across different WMF services, for
example, between the wikis and Gerrit.
(Cross-posted to wikitech-l and wikimedia-l, please copy/link elsewhere as appropriate.)
-- Tim Starling
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
Just for the record, I'm not having such problems, so it might be in some way specific to you. I've heard someone else recently complaining about getting logged in often, I don't think this is related to 2FA.
If you need to disable it, you can do it yourself (visit Preferences, click "Disable two-factor authentication" and follow the steps).
Using 2FA, no issues. Sounds more like a problem with cookies?
On Mon, Nov 21, 2016 at 3:44 PM Bartosz Dziewoński matma.rex@gmail.com wrote:
Just for the record, I'm not having such problems, so it might be in some way specific to you. I've heard someone else recently complaining about getting logged in often, I don't think this is related to 2FA.
If you need to disable it, you can do it yourself (visit Preferences, click "Disable two-factor authentication" and follow the steps).
-- Bartosz Dziewoński
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I know not. But it may be it, because the system did not seem to "remember" my password anymore either.
Anyway... BIG THANKS to Dereckson, who gave me the trick to remove the 2FA.
I am back on regular system and I set up a strong and unique password.
Anthere
Le 21/11/2016 à 17:09, Magnus Manske a écrit :
Using 2FA, no issues. Sounds more like a problem with cookies?
On Mon, Nov 21, 2016 at 3:44 PM Bartosz Dziewoński matma.rex@gmail.com wrote:
Just for the record, I'm not having such problems, so it might be in some way specific to you. I've heard someone else recently complaining about getting logged in often, I don't think this is related to 2FA.
If you need to disable it, you can do it yourself (visit Preferences, click "Disable two-factor authentication" and follow the steps).
-- Bartosz Dziewoński
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 Mon, Nov 21, 2016 at 10:42 PM, Bartosz Dziewoński matma.rex@gmail.com wrote:
Just for the record, I'm not having such problems, so it might be in some way specific to you. I've heard someone else recently complaining about getting logged in often, I don't think this is related to 2FA.
If you need to disable it, you can do it yourself (visit Preferences, click "Disable two-factor authentication" and follow the steps).
I switch devices regularly, and switch browsers also. Desktop session continues without a hitch, mostly. Mobile devices are always being logged out.
wikitech-l@lists.wikimedia.org