Si. And remember, on the first of january 2003, someone took over three sysops accounts on the french wiki, and indicated our passwords in clear to the three of us. So...well...security...hum
If we really want to be serious about security we'll have to use ssl for login, but I don't know how to do that.
-- Tim Starling
_________________________________________________________________ MSN Instant Messenger now available on Australian mobile phones. Go to http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp
On Sun, 2003-03-30 at 15:24, Tim Starling wrote:
No-one will have to reset their password. I'll just use md5(md5(password) + salt) for the new hash. The only thing users will notice is that their stored cookies will stop working and they'll have to log in again.
If that's a good enough hash, then yes that would work fine as an automated upgrade path. Hurrah!
When you've got the code ready, send it over and I'll put it up on test.wikipedia.org for a whirl.
On Sun, 2003-03-30 at 15:30, Tim Starling wrote:
If we really want to be serious about security we'll have to use ssl for login, but I don't know how to do that.
I looked into this briefly a while ago; apparently there are difficulties with using https on apache with name-based virtual servers, as it cannot determine which virtual host configuration to go to until it's already established the https connection, but to configure the https connection it needs to know which virtual host configuration it's using.
If anyone's got some experience with this or can think of a clean workaround, please speak up. (Listening on a separate port for each wiki is probably possible, but less than elegant.)
-- brion vibber (brion @ pobox.com)
On Sun, Mar 30, 2003 at 04:23:03PM -0800, Brion Vibber wrote:
On Sun, 2003-03-30 at 15:24, Tim Starling wrote:
No-one will have to reset their password. I'll just use md5(md5(password) + salt) for the new hash. The only thing users will notice is that their stored cookies will stop working and they'll have to log in again.
If that's a good enough hash, then yes that would work fine as an automated upgrade path. Hurrah!
When you've got the code ready, send it over and I'll put it up on test.wikipedia.org for a whirl.
On Sun, 2003-03-30 at 15:30, Tim Starling wrote:
If we really want to be serious about security we'll have to use ssl for login, but I don't know how to do that.
I looked into this briefly a while ago; apparently there are difficulties with using https on apache with name-based virtual servers, as it cannot determine which virtual host configuration to go to until it's already established the https connection, but to configure the https connection it needs to know which virtual host configuration it's using.
If anyone's got some experience with this or can think of a clean workaround, please speak up. (Listening on a separate port for each wiki is probably possible, but less than elegant.)
-- brion vibber (brion @ pobox.com)
You can only have one virtual host per IP/port with ssl. Sorry, SSL limitation, can't be helped. All you have to do (provided all of the wikis are on the same machine) is redirect everybody to www.wikipedia.org for the login, and then back to their original language for everything else. So, it can be done, but it is annoying.
On Sun, 2003-03-30 at 17:02, Nick Reinking wrote:
You can only have one virtual host per IP/port with ssl. Sorry, SSL limitation, can't be helped. All you have to do (provided all of the wikis are on the same machine) is redirect everybody to www.wikipedia.org for the login, and then back to their original language for everything else. So, it can be done, but it is annoying.
Hmm, that reminds me.
Way back when, I suggested* using paths instead of hostnames for the languages:
http://wikipedia.org/en/Jimmy_Carter http://wikipedia.org/eo/Jimmy_CARTER http://wikipedia.org/ko/%ec%a7%80%eb%af%b8_%ec%b9%b4%ed%84%b0
Aside from being (IMHO) more aesthetically pleasing than the current system, this would neatly solve the https problem by only using one hostname for all languages. (Old names would always be allowed on http for backwards compatibility, but not on https since we can't support that, and have no backwards compatibility URls to worry about anyway.)
* http://meta.wikipedia.org/wiki/Thoughts_on_language_integration
If this were to be done without first setting up the single sign-in system, we'd have to limit the cookie paths to the language-specific subdirectories. (Caveat: what to do about directly calling the script for diffs, edit, etc etc. This stuff needs access to the session cookie, but we want it all in a distinct place so they can be cordoned off in robots.txt, for which appending a query string after the title is insufficient.) It may also be possible to rename the cookies. Sigh... I still think the cookie/login system needs to be seriously reworked to avoid setting any cookies until actual login time to avoid scaring the paranoid.
-- brion vibber (brion @ pobox.com)
On Sun, Mar 30, 2003 at 06:35:50PM -0800, Brion Vibber wrote:
On Sun, 2003-03-30 at 17:02, Nick Reinking wrote:
You can only have one virtual host per IP/port with ssl. Sorry, SSL limitation, can't be helped. All you have to do (provided all of the wikis are on the same machine) is redirect everybody to www.wikipedia.org for the login, and then back to their original language for everything else. So, it can be done, but it is annoying.
Hmm, that reminds me.
Way back when, I suggested* using paths instead of hostnames for the languages:
http://wikipedia.org/en/Jimmy_Carter http://wikipedia.org/eo/Jimmy_CARTER http://wikipedia.org/ko/%ec%a7%80%eb%af%b8_%ec%b9%b4%ed%84%b0
Aside from being (IMHO) more aesthetically pleasing than the current system, this would neatly solve the https problem by only using one hostname for all languages. (Old names would always be allowed on http for backwards compatibility, but not on https since we can't support that, and have no backwards compatibility URls to worry about anyway.)
Not to mention squishing the wait for register.com's shitty DNS servers. Getting old links to work would still be quite easy with an Apache redirect rule.
If this were to be done without first setting up the single sign-in system, we'd have to limit the cookie paths to the language-specific subdirectories. (Caveat: what to do about directly calling the script for diffs, edit, etc etc. This stuff needs access to the session cookie, but we want it all in a distinct place so they can be cordoned off in robots.txt, for which appending a query string after the title is insufficient.) It may also be possible to rename the cookies. Sigh... I still think the cookie/login system needs to be seriously reworked to avoid setting any cookies until actual login time to avoid scaring the paranoid.
Technically, they aren't really paranoid, since we are out to get them. They just have an over-abundence of common sense. :P I can't say much about the other parts; cookie setups vary widely. Any docs on how that all works?
On 30 Mar 2003 18:35:50 -0800, Brion Vibber brion@pobox.com wrote:
Way back when, I suggested* using paths instead of hostnames for the languages:
http://wikipedia.org/en/Jimmy_Carter http://wikipedia.org/eo/Jimmy_CARTER http://wikipedia.org/ko/%ec%a7%80%eb%af%b8_%ec%b9%b4%ed%84%b0
Those would result in illegal cookies (the two-dot rule for domains).
On Mon, 2003-03-31 at 04:05, Richard Grevers wrote:
On 30 Mar 2003 18:35:50 -0800, Brion Vibber
Way back when, I suggested* using paths instead of hostnames for the languages:
http://wikipedia.org/en/Jimmy_Carter http://wikipedia.org/eo/Jimmy_CARTER http://wikipedia.org/ko/%ec%a7%80%eb%af%b8_%ec%b9%b4%ed%84%b0
Those would result in illegal cookies (the two-dot rule for domains).
No it wouldn't. They'd be set with ".wikipedia.org".
-- brion vibber (brion @ pobox.com)
Tim Starling wrote:
Si. And remember, on the first of january 2003, someone took over three sysops accounts on the french wiki, and indicated our passwords in clear to the three of us. So...well...security...hum
If we really want to be serious about security we'll have to use ssl for login, but I don't know how to do that.
Maybe just put a note on the login page that it's a low-security password.
(though you'd think people would be smart enough to use a "high secutiry" password for something like a bank once and once only... sigh...)
(Tim Starling ts4294967296@hotmail.com):
If we really want to be serious about security we'll have to use ssl for login, but I don't know how to do that.
That's entirely too paranoid. Frankly, I don't see much need for high security of Wikipedia logins. It's not like we're storing medical records. (Oh my God! My neighbor might find out that I like the "Nostalgia" skin!) The only real risk is that someone might log in as me and make edits in my name, but then I'd just disavow them and change my password.
The present saltless-md5 was an improvement over the original code which had passwords in plain text in the database where any sysop could see them all with a select; /that/ was probably a bit too loose :-), so I md5'd them. If making a slightly better encrypted version improves things with no hassle, that's fine too. But let's not get worked up over nothing.
Jimmy Wales wrote:
Lee Daniel Crocker wrote:
Frankly, I don't see much need for high security of Wikipedia logins.
Agreed. Remember that in the old wikipedia software, anyone could log in as anyone else, password or no password.
Yes, but * wikipedia was small (=little known) at that time * with all the new enhanced functions, sysops can do much more damage today ;-) * if someone hacks an administrator password (e.g., mine), a "DELETE FROM cur" would have us looking for backups pretty fast...
Magnus
On Mon, 2003-03-31 at 16:40, Magnus Manske wrote:
Jimmy Wales wrote:
Lee Daniel Crocker wrote:
Frankly, I don't see much need for high security of Wikipedia logins.
Agreed. Remember that in the old wikipedia software, anyone could log in as anyone else, password or no password.
Yes, but
- wikipedia was small (=little known) at that time
And now it's big, with a lot more people watching over it and protecting it. It takes a lot more to kill a colony of ants than a few ants.
- with all the new enhanced functions, sysops can do much more damage
today ;-)
Not really. In fact, with the enhanced user-blocking of today, there's just about nothing a rogue sysop could do that couldn't be easily reversed.
- if someone hacks an administrator password (e.g., mine), a "DELETE
FROM cur" would have us looking for backups pretty fast...
That's the only problem, and we have tons of backups.
In other words, all this paranoia is tedious and unhealthy.
On Mon, Mar 31, 2003 at 01:38:19PM -0600, Lee Daniel Crocker wrote:
(Tim Starling ts4294967296@hotmail.com):
If we really want to be serious about security we'll have to use ssl for login, but I don't know how to do that.
That's entirely too paranoid. Frankly, I don't see much need for high security of Wikipedia logins. It's not like we're storing medical records. (Oh my God! My neighbor might find out that I like the "Nostalgia" skin!) The only real risk is that someone might log in as me and make edits in my name, but then I'd just disavow them and change my password.
We should make it an option to login via SSL at least for sysops. It's pretty dangerous to send sysop passwords unencrypted.
wikitech-l@lists.wikimedia.org