Mailing List Archive

What, no salt?
Gee, the interesting things you find when browsing the wikipedia codebase.
Don't you people know what salt is? I'll give you a clue. Here's how an
attacker with access to Wikipedia's hashed passwords would currently
inverse-MD5 the passwords:

sort user table by hashed password;
foreach (possible password) {
x = md5(password_guess);
binary search table for match;
}

And here's how it would work with salt:

for (userNum=0; userNum < numUsers; userNum++) {
foreach(possible password) {
x = md5("wikipedia" + userNum + password_guess);
check for match
}
}

Some numbers: my password is 9 essentially random lower case letters. By
brute force, it would take a hacker about a week to inverse MD5 it, with one
computer. With the current scheme, if all 10000 users of Wikipedia used the
same kind of password, the hacker would successfully inverse MD5 one roughly
once every 10 minutes. He could then check those username/password
combinations against other sites -- say, Internet banking, unix accounts on
various servers, email, etc.

Don't worry, I fixed it. What do I do with the rectified code (once I've
read over it a couple more times)?

-- Tim Starling.


_________________________________________________________________
MSN Instant Messenger now available on Australian mobile phones. Go to
http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp
Re: What, no salt? [ In reply to ]
On Sun, 2003-03-30 at 07:04, Tim Starling wrote:
> Gee, the interesting things you find when browsing the wikipedia codebase.
> Don't you people know what salt is?

Nothing like reinventing a wheel to reinvent old bugs, is there? :)

> Don't worry, I fixed it. What do I do with the rectified code (once I've
> read over it a couple more times)?

By all means, send it over.

Obviously we'd have to add a note explaining that everyone has to reset
their password. Not everyone has an e-mail address attached to their
account, so we'd need to add a web form for doing this. That obviously
would require first validating the person with their current password
with the current hashing code; so we'd probably need a marker to
indicate that each users' password field is upgraded.

Of course, all our passwords are sent in cleartext over the internet
anyway, so should never be assumed to be secure.

-- brion vibber (brion @ pobox.com)
Re: What, no salt? [ In reply to ]
--- Brion Vibber <brion@pobox.com> wrote:
> On Sun, 2003-03-30 at 07:04, Tim Starling wrote:
> > Gee, the interesting things you find when browsing
> the wikipedia codebase.
> > Don't you people know what salt is?
>
> Nothing like reinventing a wheel to reinvent old
> bugs, is there? :)
>
> > Don't worry, I fixed it. What do I do with the
> rectified code (once I've
> > read over it a couple more times)?
>
> By all means, send it over.
>
> Obviously we'd have to add a note explaining that
> everyone has to reset
> their password. Not everyone has an e-mail address
> attached to their
> account, so we'd need to add a web form for doing
> this. That obviously
> would require first validating the person with their
> current password
> with the current hashing code; so we'd probably need
> a marker to
> indicate that each users' password field is
> upgraded.
>
> Of course, all our passwords are sent in cleartext
> over the internet
> anyway, so should never be assumed to be secure.
>
> -- brion vibber (brion @ pobox.com)

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

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Re: What, no salt? [ In reply to ]
>Obviously we'd have to add a note explaining that everyone has to reset
>their password. Not everyone has an e-mail address attached to their
>account, so we'd need to add a web form for doing this. That obviously
>would require first validating the person with their current password
>with the current hashing code; so we'd probably need a marker to
>indicate that each users' password field is upgraded.

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.

-- Tim Starling.

_________________________________________________________________
Re: What, no salt? [ In reply to ]
>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
Re: What, no salt? [ In reply to ]
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)
Re: What, no salt? [ In reply to ]
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.

--
Nick Reinking -- eschewing obfuscation since 1981 -- Minneapolis, MN
Re: What, no salt? [ In reply to ]
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)
Re: What, no salt? [ In reply to ]
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.

> * 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.

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?

--
Nick Reinking -- eschewing obfuscation since 1981 -- Minneapolis, MN
Re: What, no salt? [ In reply to ]
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...)
Re: What, no salt? [ In reply to ]
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).
--
What difference does it make to the dead, the orphans and the homeless,
whether the mad destruction is wrought under the name of totalitarianism or
the holy name of liberty or democracy?

Richard Grevers
Christchurch, New Zealand
Re: What, no salt? [ In reply to ]
On Mon, 31 Mar 2003 09:24:03 +1000, Tim Starling
<ts4294967296@hotmail.com> wrote:

>
>> Obviously we'd have to add a note explaining that everyone has to reset
>> their password. Not everyone has an e-mail address attached to their
>> account, so we'd need to add a web form for doing this. That obviously
>> would require first validating the person with their current password
>> with the current hashing code; so we'd probably need a marker to
>> indicate that each users' password field is upgraded.
>
> 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.
>
I hope that wikipedia isn't currently storing raw passwords in the user
table. So the only way you could implement a resetles upgrade would be to
add a second password field.
If a user logs in with only the original password field set, you validate
against that and if okay, MD5 the password they entered and store it. After
about a year you remove the original password field (anyone who hasn't
logged in in that time deserves to have to do a password reset!). I used
this technique recently to upgrade from Unix CRYPT to MD5 for password
storage.

--
What difference does it make to the dead, the orphans and the homeless,
whether the mad destruction is wrought under the name of totalitarianism or
the holy name of liberty or democracy?

Richard Grevers
Christchurch, New Zealand
Re: Re: What, no salt? [ In reply to ]
>>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.
>>
>I hope that wikipedia isn't currently storing raw passwords in the user
>table. So the only way you could implement a resetles upgrade would be to
>add a second password field.
>If a user logs in with only the original password field set, you validate
>against that and if okay, MD5 the password they entered and store it. After
>about a year you remove the original password field (anyone who hasn't
>logged in in that time deserves to have to do a password reset!). I used
>this technique recently to upgrade from Unix CRYPT to MD5 for password
>storage.

No, wikipedia isn't storing raw passwords, it's storing unsalted MD5 hashes.
But no second password field is required. We just concatenate the salt (in
this case, a concatenation of the user number and "wikipedia") to the
unsalted hash, then MD5 the whole lot again. Ordinary validation is then
conducted by calculating md5(md5(password) + salt), and comparing it with
the database value. You could have used this trick for your own upgrade. It
increases the CPU time needed for validation by a few microseconds, but one
could easily argue that's a good thing.

As an extra security measure, I realised that we could continue to use
md5(password) for our persistent session cookies. This means that a stolen
hash can no longer be used to log in.

By the way, the code is now written, and I've sent it to Brion.

-- Tim Starling.


_________________________________________________________________
Hotmail now available on Australian mobile phones. Go to
http://ninemsn.com.au/mobilecentral/hotmail_mobile.asp
Re: Re: What, no salt? [ In reply to ]
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)
Re: What, no salt? [ In reply to ]
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.

--Jimbo
Re: What, no salt? [ In reply to ]
> (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.

--
Lee Daniel Crocker <lee@piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC
Re: What, no salt? [ In reply to ]
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.
Re: What, no salt? [ In reply to ]
So, if the masses finally decide that we "need" SSL, who's paying for
the security certificate? Or would we have to plan to run without a
properly signed cert?

Of course, the certifiacte would have to be "owned" by someone. Who's
name is going to be on the certificate? Bomis'? That wouldn't make
sense, since we'd have to get a new one when the non-profit is set up.

Whether SSL is a good idea in this situation isn't the issue. Setting
it up properly involves getting some other things done first. IMHO,
Moving forward on SSL at this point would be slightly premature.

Jason

Tomasz Wegrzanowski wrote:

> 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 mailing list
> Wikitech-l@wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikitech-l

--
"Jason C. Richey" <jasonr@bomis.com>
Re: What, no salt? [ In reply to ]
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
Re: What, no salt? [ In reply to ]
On Mon, 31 Mar 2003, Jason Richey wrote:
> So, if the masses finally decide that we "need" SSL, who's paying for
> the security certificate? Or would we have to plan to run without a
> properly signed cert?

I have no problem with a self-signed cert; the idea is mainly to keep
cleartext passwords off the public internet, not to verify that some
megacorp has a physical address to track Wikipedia down if we steal
someone's money without sending them their purchase.

If people want something that's been rubber stamped by a large corporation
hundreds or thousands of miles away which probably won't actually bother
to verify that we are who we say we are, they'll have to pony up the
cash.

We haven't paid RSA or VeriSign a bajillion dollars to verify our SSH
server key, either, but I feel a lot better using ssh to login and give
the databases a stir than I would using telnet.

> Of course, the certifiacte would have to be "owned" by someone. Who's
> name is going to be on the certificate? Bomis'? That wouldn't make
> sense, since we'd have to get a new one when the non-profit is set up.

So Jimbo, how's the non-profit coming along? :)

-- brion vibber (brion @ pobox.com)
Re: What, no salt? [ In reply to ]
On Mon, Mar 31, 2003 at 01:37:35PM -0800, Jason Richey wrote:
> So, if the masses finally decide that we "need" SSL, who's paying for
> the security certificate? Or would we have to plan to run without a
> properly signed cert?
>
> Of course, the certifiacte would have to be "owned" by someone. Who's
> name is going to be on the certificate? Bomis'? That wouldn't make
> sense, since we'd have to get a new one when the non-profit is set up.
>
> Whether SSL is a good idea in this situation isn't the issue. Setting
> it up properly involves getting some other things done first. IMHO,
> Moving forward on SSL at this point would be slightly premature.

Passive attacks are very easy and very common,
active attacks are much more difficult and
a couple orders of magnitude more rare.

We don't really need to care about someone signing our certs.
We have much bigger security holes anyway ;)
Re: What, no salt? [ In reply to ]
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.

There are two reasons to have good security:

1) To prevent hijacking of an administrator/developer account.
2) To prevent password theft. Many users use the same password for a number
of sites.

Of course, users who know anything about Internet security should expect
websites to handle their passwords insecurely -- everyone does it. Wikipedia
is certainly not alone.

>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.

SSL is indeed a big hassle for a relatively small gain. I once read an
article on what someone can do if they have physical access to the network
-- say in a campus network using old thin-wire ethernet. It was pretty
scary, actually -- they can basically intercept and modify all
communications at will. But this kind of attack does require physical
access, and hence is reasonably rare. Remember that even SSL won't fix
another common kind of attack -- a user system compromised by a worm or
trojan. There's not much we can do about that one, but it happens all the
time.

-- Tim Starling.


_________________________________________________________________
Re: What, no salt? [ In reply to ]
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.
Re: What, no salt? [ In reply to ]
Jason Richey wrote:
> So, if the masses finally decide that we "need" SSL, who's paying for
> the security certificate? Or would we have to plan to run without a
> properly signed cert?

I would pay for this if we needed it, but we don't, so it's a moot
point. :-)