[Wikitech-l] MD5 Password Encryption

classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[Wikitech-l] MD5 Password Encryption

Edward Z. Yang
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If I am not mistaken (and I may very well be), MediaWiki still uses MD5s
to encrypt (well, technically hash, but it's named wfEncryptPassword(),
heh heh) user passwords.

function wfEncryptPassword( $userid, $password ) {
        global $wgPasswordSalt;
        $p = md5( $password);

        if($wgPasswordSalt)
                return md5( "{$userid}-{$p}" );
        else
                return $p;
}

If this is indeed the case, we should be considering migrating away from
MD5 to a more secure algorithm like SHA256. The breadth of attacks
against this hashing scheme have grown incredibly sophisticated, and
over where I consult, we generally discourage new developers from using
MD5 for any security related purposes (still makes a fine good checksum
though).

Migrating the hashes would probably prove to be tricky, but if we
implement appropriate hooks, with the addition of only one new field we
could easily "magically" update the fields once a user logs in, and the
system is (for one short request) in possession of the plaintext
password. The old algorithm could be supported indefinitely, but only
for old user accounts that haven't upgraded yet, all new accounts would
use the new hashing scheme. We could even rename the function into
something more accurate!

What say the developers?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtWicqTO+fYacSNoRAmQEAJ45Laiqabiclzix0wZ8cN2Y8CuVZACffFUB
DYyZ9MjWOhFalNSY73bpM0w=
=9sel
-----END PGP SIGNATURE-----


_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Simetrical
On 1/22/07, Edward Z. Yang <[hidden email]> wrote:
> If this is indeed the case, we should be considering migrating away from
> MD5 to a more secure algorithm like SHA256. The breadth of attacks
> against this hashing scheme have grown incredibly sophisticated, and
> over where I consult, we generally discourage new developers from using
> MD5 for any security related purposes (still makes a fine good checksum
> though).

Aren't the vulnerabilities limited to the attacker creating a
collision of two strings *that the attacker created* sharing a common
prefix?  Are they relevant to a password hash?  There's no preimage
attack against MD5, and that strikes me as the only thing relevant to
passwords.  Things like certificates can be a problem, of course,
depending on exact implementation.

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Brion Vibber
In reply to this post by Edward Z. Yang
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Edward Z. Yang wrote:
> If I am not mistaken (and I may very well be), MediaWiki still uses MD5s
> to encrypt (well, technically hash, but it's named wfEncryptPassword(),
> heh heh) user passwords.
[snip]
> If this is indeed the case, we should be considering migrating away from
> MD5 to a more secure algorithm like SHA256.

As a note; AFAIK versions of PHP prior to 5.1.2 include only MD5 and
SHA-1 digest functions built-in, and the rumor is SHA-1 isn't safe
enough either.

There is an 'mhash' module with more algos including SHA256, but it
appears not to be enabled by default:
http://www.php.net/manual/en/ref.mhash.php

The more featureful 'hash' module is available by default from 5.1.2 on:
http://www.php.net/manual/en/ref.hash.php

Currently MediaWiki supports PHP 5.0.4(?) and up, but 5.0 is mildly
annoying (and has some nasty breakage with arrays causing  it to fail on
64-bit systems.)


With appropriate hash functions present, we could indeed auto-upgrade
hashes on login. (A new field is not necessarily required; the existing
hash field can be upgraded to indicate the hash algo along with the hash
value. And in a happy case of coincidence, the password hash fields are
tinyblobs, so anything that fits in 255 bytes is cool...)

- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtXKuwRnhpk1wk44RAqZKAJ9YoUN2Ea1VK+Aw9Y4LNEokgwcuWQCdFhYl
hu5nuA+yHUkJ4+fUtbVpWGE=
=WQS2
-----END PGP SIGNATURE-----

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Edward Z. Yang
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brion Vibber wrote:
> As a note; AFAIK versions of PHP prior to 5.1.2 include only MD5 and
> SHA-1 digest functions built-in, and the rumor is SHA-1 isn't safe
> enough either. [snip]

I would recommend rolling a pure-PHP implementation of SHA-256 and
siwtching to the hash implementation if it is present. The hash isn't
computed very often: only during login and password setting, so any
performance penalty incurred wouldn't be that bad. Plus, there are
already a number of quite fast SHA-256 implementations out there for
PHP. I personally recommend: <http://code.tatzu.net/sha256/>

> With appropriate hash functions present, we could indeed auto-upgrade
> hashes on login. (A new field is not necessarily required; the existing
> hash field can be upgraded to indicate the hash algo along with the hash
> value. And in a happy case of coincidence, the password hash fields are
> tinyblobs, so anything that fits in 255 bytes is cool...)

Works then, since raw binary SHA-256 output is only 256 bits (64 bytes,
I believe). We can easily spare another 7 bytes to prepend it with
something along the lines of "sha256:"

Simetrical wrote:
> Aren't the vulnerabilities limited to the attacker creating a
> collision of two strings *that the attacker created* sharing a common
> prefix?  Are they relevant to a password hash?  There's no preimage
> attack against MD5, and that strikes me as the only thing relevant to
> passwords.  Things like certificates can be a problem, of course,
> depending on exact implementation.

Well, in spite of these extremely devastating attacks in the collision
area, the keyspace of MD5 is extremely small: 128 bits is small enough
that a birthday attack is extremely feasible. MD5 also has many
comprehensive rainbow tables (including one that's 4.9 TB large!) I
think it's worth migrating, even if the security increase is
comparitatively small. It's not difficult to do.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtXgoqTO+fYacSNoRAlD+AJ4rbqYappCdINOnd04L+2c/XxpDKACeJNWu
HxrsAq6hlrMjKKOk//inoUE=
=3wk3
-----END PGP SIGNATURE-----


_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Ivan Krstić-2
Edward Z. Yang wrote:
> I would recommend rolling a pure-PHP implementation of SHA-256 and
> siwtching to the hash implementation if it is present.

New crypto implementations often have far more security issues than the
primitives they're implementing. Despite the known attacks on SHA-1,
it's perfectly fine for password hashing, and it doesn't require
external libraries. Use it, be merry.

--
Ivan Krstić <[hidden email]> | GPG: 0x147C722D

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Edward Z. Yang
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ivan Krstić wrote:
> New crypto implementations often have far more security issues than the
> primitives they're implementing. Despite the known attacks on SHA-1,
> it's perfectly fine for password hashing, and it doesn't require
> external libraries. Use it, be merry.

Actual encryption (both design and implementation) is indeed rocket
science, but implementing cryptographic hashes is not difficult at all
as long as you understand the algorithm and a good battery of unit tests
to make sure your implementation is working properly.

Yes, actually *designing* a hash function is difficult. And yes, SHA-1
*probably* is still good enough. But if we're going to go the trouble of
migration (small trouble, but trouble that requires DB schema changes
nonetheless (be they formal or informal)), we might as well do it right.
I remember one security expert saying that there is no smoke yet, but
the alarm bells have gone off for SHA-1 and it's time to walk (not run)
for the exits.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtXvcqTO+fYacSNoRApoGAJ9Puqsb5SRQoJJtMf4JNzCMJ32B7QCdG7D0
Wj9X9jjaIV3WSiduM46XJXs=
=eN5t
-----END PGP SIGNATURE-----


_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Anthony-61
In reply to this post by Edward Z. Yang
On 1/22/07, Edward Z. Yang <[hidden email]> wrote:
> Well, in spite of these extremely devastating attacks in the collision
> area, the keyspace of MD5 is extremely small: 128 bits is small enough
> that a birthday attack is extremely feasible. MD5 also has many
> comprehensive rainbow tables (including one that's 4.9 TB large!) I
> think it's worth migrating, even if the security increase is
> comparitatively small. It's not difficult to do.

A birthday attack is not relevant to a password hashing scheme, and
rainbow tables are useless since Mediawiki uses salts.

The fact that the keyspace of MD5 is only 128 bits does limit the
password strength, but who's using a password more than 13 characters
for their Wikipedia password?  Does Mediawiki even allow more than 13
character passwords?

Anthony

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Simetrical
On 1/22/07, Edward Z. Yang <[hidden email]> wrote:
> Well, in spite of these extremely devastating attacks in the collision
> area, the keyspace of MD5 is extremely small: 128 bits is small enough
> that a birthday attack is extremely feasible.

Birthday attack, maybe, but that's useless for cracking a password.
It's still far too large to brute-force a preimage.  Maybe not for too
many years to come . . . I don't disagree with the idea of moving to a
new hash function just to be safe.  It seems like a good idea.

(While we're on the topic of hashes, by the way, vBulletin has
JS-enabled browsers hash and salt their passwords before they even
send them.  Thus man-in-the-middle attacks are impossible.  Seems like
a nifty idea to consider, anyway.)

On 1/22/07, Anthony <[hidden email]> wrote:
> The fact that the keyspace of MD5 is only 128 bits does limit the
> password strength, but who's using a password more than 13 characters
> for their Wikipedia password?  Does Mediawiki even allow more than 13
> character passwords?

I think the limiting factor in password length in MediaWiki is how
large a POST the server is willing to accept.  ;)  I once tried a
password on my local install thousands of pages long, just for the
heck of it, and it worked fine.

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Ivan Krstić-2
In reply to this post by Edward Z. Yang
Edward Z. Yang wrote:
> implementing cryptographic hashes is not difficult at all
> as long as you understand the algorithm and a good battery of unit tests
> to make sure your implementation is working properly.

Yes, and jet turbine maintenance is not difficult at all as long as you
understand their construction and have a good battery of pre-flight
tests to make sure they're working properly. Yet you wouldn't feel very
comfortable grabbing a random person off the street, handing them the
manual, and having them go to town on the engines of your 747.

It's trivial to introduce all sorts of subtle bugs when creating new
crypto implementations -- we've seen this happen time after time -- so
unless there's a particularly compelling reason to reimplement from
scratch, sticking with something that's already out and has had many
eyeballs looking at it is almost always the correct choice.

> But if we're going to go the trouble of
> migration (small trouble, but trouble that requires DB schema changes
> nonetheless (be they formal or informal)), we might as well do it right.
> I remember one security expert saying that there is no smoke yet, but
> the alarm bells have gone off for SHA-1 and it's time to walk (not run)
> for the exits.

FUD. Talk of "doing it right" and "alarm bells having gone off" is
meaningless without a threat model. New uses of SHA-1 are rightly
discouraged in protocol design, where collisions directly translate to
potential problems, but password hashing?

Generally, the only password hashing scenario in which the choice of
algorithm makes a difference at all is an offline attack once the
password table has been compromised, at which point, the difference
between one algorithm and the next is nothing more but how long you can
hold off a brute-forcing attacker. And for that, without preimage
attacks, the known MD5 and SHA-1 flaws make about zero difference for
any practical purpose.

--
Ivan Krstić <[hidden email]> | GPG: 0x147C722D

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Gregory Maxwell
On 1/22/07, Ivan Krstić <[hidden email]> wrote:
[snip]
> Generally, the only password hashing scenario in which the choice of
> algorithm makes a difference at all is an offline attack once the
> password table has been compromised, at which point, the difference
> between one algorithm and the next is nothing more but how long you can
> hold off a brute-forcing attacker. And for that, without preimage
> attacks, the known MD5 and SHA-1 flaws make about zero difference for
> any practical purpose.

Ivan is right on in his statements here.

There might be good reasons to move.. for example, as part of an
overall effort to stop using legacy hash functions throughout the
software... or better, to change to a system which supports client
side hashing.

None of the pre-existing MD5 rainbow tables will do a lick of good
against mediawiki because of the weird legacy inspired H(s+'-'+H(P))
that we use.

Frankly, we could probably be using classic unix crypt() for this
application. Hashing our server side passwords is useful to make it
less attractive for someone to steal the database, and perhaps keep a
curious developer from doing something actually useful like publishing
a list of accounts with the same password.

Once we've succeeded in making sure that attacking the database of
passwords is no longer the lowest hanging fruit, we're pretty much
done... Taking the extra effort to add lots of additional security
will only risk adding additional vulnerabilities.

(/me waits for someone to notice my above H(s +'-'+H(P)) above and cry
about the minor precomputation a smart attacker can do to reduce the
workload from 2*users*passwords MD5s to passwords + passwords*users
MD5s)

If someone wants to add something that will substantially improve
security which requires no substantial changes, ... build something
like Google's password strength indicator for the password change
page. :) (bonus points for pure js rather than ajax based)
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Mark Clements (HappyDog)
In reply to this post by Simetrical
"Simetrical" <[hidden email]>
wrote in message
news:[hidden email]...
> On 1/22/07, Anthony <[hidden email]>
wrote:
> > The fact that the keyspace of MD5 is only 128 bits does limit the
> > password strength, but who's using a password more than 13 characters
> > for their Wikipedia password?  Does Mediawiki even allow more than 13
> > character passwords?
>
> I think the limiting factor in password length in MediaWiki is how
> large a POST the server is willing to accept.  ;)  I once tried a
> password on my local install thousands of pages long, just for the
> heck of it, and it worked fine.

And could you remember it the next time you tried to log in? :-)


- Mark Clements (HappyDog)




_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Simetrical
On 1/22/07, Mark Clements <[hidden email]> wrote:
> And could you remember it the next time you tried to log in? :-)

Well, I believe it consisted entirely of the letter 'A', so possibly I
could have if I wanted to.  :P

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Brion Vibber
In reply to this post by Simetrical
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Simetrical wrote:
> (While we're on the topic of hashes, by the way, vBulletin has
> JS-enabled browsers hash and salt their passwords before they even
> send them.  Thus man-in-the-middle attacks are impossible.  Seems like
> a nifty idea to consider, anyway.)

I did a demo implementation of that a couple years ago (might be in SVN
somewhere, or might be lost) on this model:

- - server sends a challenge string C with the login form
- - JavaScript takes over on form submission, asking server for the salt
(user id) for the given name
- - client calculates the salted hash H
- - client calculates a combined hash, something like MD5(c + H), and
submits that with the form instead of plaintext
- - server confirms that the submitted combined hash matches what it can
calculate with the challenge string and its copy of H

Is it more secure than sending plaintext passwords? A bit. But even if
the challenge can armor against replay attacks, anyone sniffing can just
hijack the session cookie and do all manner of nasty things right then
and there.

There was some muttering at the time that just using HTTPS is safer and
it's not worth the bother. Agreement? Disagreement?

- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFta3XwRnhpk1wk44RAoS6AJ93zpLEoXoAMKQDwfBMTFw3AS1FnQCfXmBs
rotOXAaYzYzNC8ailwO6pMY=
=h4i6
-----END PGP SIGNATURE-----

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Rob Church
On 23/01/07, Brion Vibber <[hidden email]> wrote:
> There was some muttering at the time that just using HTTPS is safer and
> it's not worth the bother. Agreement? Disagreement?

What infrastructure changes would it require for us to start migrating
to HTTPS, at least during the login process?


Rob Church

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Gerard Meijssen-3
Rob Church schreef:

> On 23/01/07, Brion Vibber <[hidden email]> wrote:
>  
>> There was some muttering at the time that just using HTTPS is safer and
>> it's not worth the bother. Agreement? Disagreement?
>>    
>
> What infrastructure changes would it require for us to start migrating
> to HTTPS, at least during the login process?
>
>
> Rob Church
Hoi,
I would say first finish the Single User Login. It makes little sense to
consider it before this implementation as it is part of the login process.
Thanks,
     GerardM

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Rob Church
On 23/01/07, Gerard Meijssen <[hidden email]> wrote:
> I would say first finish the Single User Login. It makes little sense to
> consider it before this implementation as it is part of the login process.

*shrug*

All I did was ask what kind of changes we would need to plan for. You
know, if we require a few hundred new servers, we might as well whinge
about that at the next budget allocation now, so we can plan ahead.

I don't see you rushing to help with single-user login. Nor do I see
any of those people who're whinging about it taking ages, and how they
could do better, coming up with any better implementations.

This next bit isn't aimed at you Gerard...CAN PEOPLE PLEASE LAY OFF ON
SINGLE USER LOGIN? It's driving us all mad everytime someone asks
"when and how", and if I were Brion, I'd be getting absolutely bloody
*sick* of it. Furthermore, "SUL" is *not* some magical sword which
will fix all our problems in one fell swoop, so please remember that.


Rob Church

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Gerard Meijssen-3
Rob Church schreef:

> On 23/01/07, Gerard Meijssen <[hidden email]> wrote:
>  
>> I would say first finish the Single User Login. It makes little sense to
>> consider it before this implementation as it is part of the login process.
>>    
>
> *shrug*
>
> All I did was ask what kind of changes we would need to plan for. You
> know, if we require a few hundred new servers, we might as well whinge
> about that at the next budget allocation now, so we can plan ahead.
>
> I don't see you rushing to help with single-user login. Nor do I see
> any of those people who're whinging about it taking ages, and how they
> could do better, coming up with any better implementations.
>
> This next bit isn't aimed at you Gerard...CAN PEOPLE PLEASE LAY OFF ON
> SINGLE USER LOGIN? It's driving us all mad everytime someone asks
> "when and how", and if I were Brion, I'd be getting absolutely bloody
> *sick* of it. Furthermore, "SUL" is *not* some magical sword which
> will fix all our problems in one fell swoop, so please remember that.
>
>
> Rob Church
Hoi,
Actually I will not lay off on Single User Login. The reason is quite
simple. Some things that are important to me will not happen until AFTER
Single User Login. It is all well and good that everyone comes up with
the most nifty things and all kinds of functionality that HAS to be
implemented because you are volunteers too. In the mean time some rather
basic stuff does not get done. If this drives you mad, fine. Fix the
issue - help Brion implement SUL !

The promised date for SUL was end of January 2005. It is now a year late.

Thanks,
    GerardM


_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Ivan Krstić-2
In reply to this post by Brion Vibber
Brion Vibber wrote:
> There was some muttering at the time that just using HTTPS is safer and
> it's not worth the bother. Agreement? Disagreement?

Absolutely agreed. Not being able to deal with the computational cost of
SSL is the only convincing reason to try and use JavaScript hackery to
do a more secure login, and I don't think that's a valid concern at
Wikipedia these days. If you find a designated SSL login machine becomes
CPU-bound, I can recommend PCI SSL accelerator cards that'll be happy to
take over the work.

--
Ivan Krstić <[hidden email]> | GPG: 0x147C722D

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Platonides
In reply to this post by Brion Vibber
Brion Vibber wrote:
> There was some muttering at the time that just using HTTPS is safer and
> it's not worth the bother. Agreement? Disagreement?


Probably HTTPS is safer, though JS challenges are easier to implement.
Still, the https server needs to send the user back to the 'normal' page
with some token, as it can't set the logged cookie.
The http protocol was enhaced with some response codes 'changing to
secure mode', so it might be feasible produce the login over https with
the same server but i don't know the state of current implementations
(both client and server), could be tricky.

As SUL will change the authentication schemas, close accounts, etc. it
IS the appropiate moment to change hashes on the 'joined' accounts, set
a login https server, etc.


_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] MD5 Password Encryption

Anthony-61
In reply to this post by Gerard Meijssen-3
On 1/23/07, Gerard Meijssen <[hidden email]> wrote:

> Hoi,
> Actually I will not lay off on Single User Login. The reason is quite
> simple. Some things that are important to me will not happen until AFTER
> Single User Login. It is all well and good that everyone comes up with
> the most nifty things and all kinds of functionality that HAS to be
> implemented because you are volunteers too. In the mean time some rather
> basic stuff does not get done. If this drives you mad, fine. Fix the
> issue - help Brion implement SUL !
>
> The promised date for SUL was end of January 2005. It is now a year late.
>
> Thanks,
>     GerardM
>
I couldn't agree with this more.  Single User Login is a pretty
useless feature.  It was a neat dream back in 2001 or whenever
passport.com came out, but it really is rather useless.  But...there
are so many other useful features that are being ignored because they
aren't scheduled to be implemented until *after* SUL.

I really wish the board would fix the issue and tell Brion to just
drop the whole idea of Single User Login.  You know, Firefox (like
probably all the other browsers) has this nifty feature that stores
your username and password for each site, so you only have to type in
your password once.

By the way, January 2005 was *two* years ago, not one.

Anthony

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
123