On Thu, Aug 19, 2010 at 5:16 PM, Lane, Ryan Ryan.Lane@ocean.navo.navy.mil wrote:
Though SMS has a number of vulnerabilties, as listed in the link, in practical terms, it is likely to be safer than email for one time passwords. Remember: one time passwords are used as a form of two factor authentication. The SMS is sent to something they have after the user enters the thing they know. The thing you know in this system is often a password. People tend to use the same password everywhere, and a user's wikipedia password is likely their email password, which would make a one time password sent to the email less effective.
With SMS, an attacker would have to know the user's password, and would have to intercept the SMS, which isn't easy enough to be worth the trouble.
I don't get what you're suggesting here. Every time a user logs in, they need to both enter their password and follow a link in a text message? Do you think that more than a double-digit number of Wikipedia users would actually opt into this? Or are you talking about support in MediaWiki to be used on high-security corporate or government sites, not Wikipedia?
If someone is willing to do the work, I'm not objecting to supporting this in the software, but if we're talking about Wikipedia, it doesn't make sense to try going this far.
But it is, if the private key is stored on a thumb drive (in a crypto application), or on a smart card. Even if the private key and password are stored on the filesystem unencrypted, an x509 key is safer than a password simply because it is *much* more complex, so it is very unlikely to be brute forced.
Yes, certificates are usually more secure than passwords.
This is a pretty smug statement.
I don't think so. I think it's completely reasonable, when talking about Wikipedia. Hackers go after money, and there's no money in hacking Wikipedia. We have nothing secret or valuable that's not already readily available. We have no black-market competitors who want to try disrupting our service. Any malicious action could be easily reversed. The worst we have to worry about is someone with a grudge trying to frame someone else, which has happened, but it's hardly a pressing concern.
I seriously cannot see more than a few dozen Wikimedia users actually going to the effort of using one-time passwords over SMS just to protect their account. Consequently, it's not reasonable to ask Wikimedia sysops to do the deployment work necessary for sending SMS from Wikimedia servers, if it's nonzero. Nor is it reasonable to have the code reviewed, and the option offered (we already have too many options), when there's so little benefit.
Every feature has an inherent cost in code maintenance and complexity of use, so features that are too marginal should not be part of the software.
I think it would be nice to offer more secure methods of authentication to users who choose to take advantage of them. One time passwords would likely be too confusing to force on everyone, but they aren't too confusing to offer as an option. It also isn't very difficult to implement on the authentication server's end either. Also, if we are to act as an OpenID provider, it would be pretty nice to offer these more secure alternatives.
There is no point in providing options that virtually no one will use. It wastes the effort of all the people who have the maintain the relevant code, and it's yet more distraction on our already way-too-bloated preferences page. And it will not be useful to anyone when someone turns on the preference by mistake and can now no longer log in because they gave a phone number that doesn't receive SMS, or whatever. When few enough people want a preference that more people are likely to turn it on by mistake than deliberately, and when there's significant harm or confusion from turning it on by mistake, that's a sign that it's a bad preference. (See also: "Use external editor".)
Do you think that more than 0.01% of Wikimedia users will enable any such preference if provided?