Edward Z. Yang 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. -- Ivan Krstić <krstic(a)solarsail.hcs.harvard.edu> | GPG: 0x147C722D

Edward Z. Yang wrote: 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. 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ć <krstic(a)solarsail.hcs.harvard.edu> | GPG: 0x147C722D

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moin, On Tuesday 23 January 2007 05:10, Gregory Maxwell wrote: [snip] I agree that changing the hashing algorithm is unnec. here. But: Actually, if you want to strengthen the password-hash table against some offline brute-force/dictionary attacks, you should hash them with a function that takes a long time per test, but still not enough time to slow down the log-in servers. Something like hash = H(password); for (0..100) { hash = H(hash); } What function you actually use for H(), may it be MD5 or SHA1, is practically irrelevant here, tho, but when you migrate to such a scheme, you might as well use SHA256 instead of MD5 (even if it is just to quiten all the "MD5 is insecure" cryers :) Best wishes, Tels - -- Signed on Tue Jan 23 18:45:25 2007 with key 0x93B84C15. View my photo gallery: http://bloodgate.com/photos PGP key on http://bloodgate.com/tels.asc or per email. "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." -- Howard Aiken

Mark Clements schreef: Hoi, This discussion /is /about changing the security. Changing it because the need is felt for the current system to be improved. So when you have the option between several choices where one is theoretically substantially better, it is worth the consideration. As many people have mentioned it pays to use well tested, well known algorithms. As many people have mentioned, it pays to double check that the implementation is done perfectly. Public perception about security is important. When people think that something is not secure, they are a step closer to proving that something is not secure. Thanks, GerardM

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aw, come on, why is there so much contention about such a simple issue? And yes, I did slip when I started talking about birthday attacks. Sorry about that. - From the way I see it, then, the primary objections with migrating are that: * All this hashing and salting tomfoolery makes no difference because the only way an attacker could possibly get the hashes is if they hacked into the server or a developer with full-read access pulled the hashes. * The current way is not broken, because there have been no pre-image attacks developed for MD5 * Effort spent on migration would be better spent on HTTPS * The security benefit is miniscule, compared to other possible strategies such as encouraging strong passwords * And that I have no clue what I'm talking about (I like to think that I at least have some clue) There are some periphery issues surrounding SHA256: * SHA-256 is not as widely deployed, so it might have some fatal weaknesses. (it's unlikely, though, because it is still based off of SHA-1) * SHA-256 would require a pure-PHP implementation which might have bugs (Due to the avalanche effect, however, any bug should be glaringly obvious. Furthermore, the algorithm is small enough so that a full code audit would not be difficult to do (think <15kb)) My arguments for migrating are: * Defence in depth: it is true that there are a number of elements that already potentially should "solve" the problem, but this argument taken to the extreme would mean there would be no need to hash or salt the password at all: after, anyone who has access to the database could just change it themselves! But I'm sure most reasonable people here agree that hashing the password is better than no protection at all, even if it doesn't seem to make a difference. * It saves effort later: By adding support for multiple hashing techniques, and building the framework necessary to migrate these hashes, we reduce the cost of any other hash migrations we have to do in the future down. If done properly, a future migration could be done by specifying a new hash function, and the code from the previous migration would do all the work. * It is forward thinking: attacks against hashing schemes never grow worse: they only get better, as processing power, memory capabilities and knowledge of attacks increase. It's no problem if we don't, of course. The strangeness of MediaWiki's current hash function should, for now, prevent people from using rainbow tables to find the password (even though you reduce entropy by double-hashing). But, as I said, defense in depth! Now, about that password security indicator...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alphax (Wikipedia email) wrote: First of all, SHA1 is not *broken*: although cryptographers have discovered ways to force collisions at a rate lower than brute-force, the attack is still not practical. Furthermore, in a message signing context, you would need to trick me into signing a doctored message, which would be pretty much impossible as I almost always only use GPG to sign plaintext. Furthermore, I'm currently using a DES signature, which uses 160 bits and thus does not support SHA-256. I could use RSA, but then encryption would be out of question. What you SHOULD be asking is why I'm using an old version of GnuPG (the current version is 1.4.6). Don't know why, my archived copy gives similar results. Maybe Thunderbird did something to it.

On 1/22/07, Edward Z. Yang &lt;edwardzyang(a)thewritingpot.com&gt; wrote: 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

"Simetrical" &lt;Simetrical+wikitech(a)gmail.com&gt; wrote in message news:7c2a12e20701221939h45f35021u6e37e067ba078df2@mail.gmail.com... wrote: And could you remember it the next time you tried to log in? :-) - Mark Clements (HappyDog)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simetrical wrote: 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)

Rob Church schreef: 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

Rob Church schreef: 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

Anthony wrote: SUL isn't generic SSO. Clearly, you have little or no understanding of the kind of problems that SUL is trying to fix or the benefits it would bring, so I'm not sure why you thought it was a good idea to embarrass yourself on a public list by backing ignorance with invective. You aren't entitled to getting your desired MediaWiki features implemented by other people. If the current development model or pace bother you, either focus on your power animal and find the patience to wait some more, or start posting patches. -- Ivan Krstić &lt;krstic(a)solarsail.hcs.harvard.edu&gt; | GPG: 0x147C722D

On 24/01/07, Anthony &lt;wikitech(a)inbox.org&gt; wrote: That's enough lame attacks, please, kthx. Rob Church

On 24/01/07, Anthony &lt;wikitech(a)inbox.org&gt; wrote: It's *all* lame, and it's *all* pointless bickering. We're supposed to be techies; we're supposed to discuss things and be normal (to our standards). Let's maintain civilised discussion on the mailing lists, please. Rob Church

Anthony wrote: Actually, digital identity management is more important than ever, and this time it looks like it's going to be done right. SUL is an important part of helping make that happen for Wikipedia and all of its attendant projects. -- Neil

Hoi, Basic stuff that does not get done? To me the fact that all Marathi projects are doing the localisation for EVERY of their project is extremely basic. This is something that can be fixed. And if I can help it, I will try to get it fixed in such a way that such situations will not happen in the future. I am not a developer and I am busy as it is doing other things to become one. It is clear that the Wikimedia Foundation wants to extend the number of developers. If I were doing the hiring I would particularly be interested in people that make sure that the procedures are efficient .. This would make sure that the valuable time of developers is spent as little as possible on these type of things. It would also mean that stupid anomalies as having people to learn developer procedures in order to get their language supported would not exist. It is stupid because supporting projects and their languages well is the second highest priority after the continued service of our infrastructure. When both these things work well, only then there would be room for new functionality. The next thing to consider is what has priority, the continued unabated rush to get new functions in, or is it wise to stop including such functionality until some of the projects that /are /prioritised by the WMF become a reality. If this means that Brion does not do anything but SUL for a month on new functionality until SUL gets done, it would be in your interest to help him in order to get your stuff in production. You make a comparison to Microsoft; in many ways MediaWiki is on the other end of the spectrum when it comes to release management. Luckily on both ends of the spectrum great things happen. Both the Windows and the MediaWiki fan-boys have plenty to cheer about. Both have different parts of the puzzle to make for an optimal product and both have problems getting major new inventions integrated. Thanks, GerardM Rob Church schreef:

Nick Jenkins schreef: Both Brion and Tim are no volunteers, it is perfectly reasonable for the WMF to indicate that specific things have a priority. This may mean that people do not get their attention with what they volunteered to develop at the moment they are done with it, it would be perfectly reasonable. Because not only developers are volunteers. You make it as if it is you developers that dictate what happens. As to Brion's time, you can only get so many pork chops out of a pig. :) This would be completely and utterly insane. As I indicated before, the first priority is the continued running of the services. With Brion and or Tim flown to Antartica, these services are likely to suffer a lot. Then and only then comes new functionality including SUL. We surely disagree on what has urgency, to me the first thing after what has already been given priority is the needed improvement of the basic running of the localisation for languages like Marathi. It is ridiculous to consider that things that are "nice to have" are given priority when things that are manifestly broken are not fixed. Given that the Wikimedia Foundation claims that it is important that people are able to edit in their language, the consequence is that this is given priority. Failing to do so is what is considered to be discrimination. Given that Brion is the release manager, he is the one who has to look at the code that Nikerabbit has produced. It has to be accepted and implemented. It is code that is there, it needs his stamp of approval. When you think that all what you produce in code should have priority over what will help operationally on the most basic level, please explain. Thanks, GerardM

Rob Church schreef: Great to know that more people feel strongly about this.. :) Why reject new functionality? That is NOT what I want to see happen. Not at all. What I want to see happen is that certain things come to conclusion. It is awful when because some developer made something that is pretty things that are basic functionality have to wait. I would not reject new functionality, I would give it its priority and this means that it will gets assessed and implemented at the appropriate time. The problem is that Brion does not scale and neither does Tim. There are plenty of other BASIC things that need doing. Getting the Marathi localisation from the Marathi Wikipedia is just one. As you agree that getting the localisation for all our languages having regular updates, it needs some work to get the language files for ALL languages a language file and make sure that the procedure for new languages includes the creation of a language file. It makes the ground fertile for when Brion has the time to check out the BetaWiki software. Thanks, GerardM

Rob Church wrote: You will need one IP address per HTTPS server name, since you cannot virtual-host HTTPS: however, there's nothing to stop a single machine from having as many IP addresses as desired, and thus as many HTTPS servers as desired. This also means that load-balance cannot "look into" the encrypted HTTPS connection to see where to send the traffic to: it will have to go by the destination IP address. However, HTTPS can still be load-balanced, you just need a different external IP address for each visible service, and one internal IP address for each HTTPS service on each server within the load-balancing cloud. A lot of this could, of course, be made much simpler if you only had a single HTTPS server URL for login in each project, such as https://login.wikipedia.org/ -- this would fit rather well with the unified login idea. The servers would need to have their certificates signed by a well-known CA, or browsers will complain (as, for example, occurs with https://wikitech.leuksman.com). Ideally, images, style sheets and other media within the login pages should also be served over HTTPS, ideally from the same server, or some browsers will complain. HTTPs has a small but significant per-session overhead to perform the initial authentication and key exchange (but not per-hit, since the authentication information can be cached between multiple connections within the same session.) There is also a small extra overhead for all data passed over the encrypted connection, which has to be compressed/decompressed and encrypted/decrypted on the fly as necessary; however, this last is going to be pretty unimportant if all you use it for is to serve login pages. -- Neil

only IP based virtual hosting, as the SSL connection happens before the request is made. So, if you have two virtual hosts such as: <Virtualhost en.wikipedia.org> ... </Virtualhost> <Virtualhost de.wikipedia.org> ... </Virtualhost> The first virtual host will always be used as the server has absolutely no clue, when the connection is made, which virtual host it needs to use. I believe this is the point Neil was trying to make. V/r, Ryan Lane

Tim Starling wrote: And, once the various browsers and CAs have all sorted out the different ways of generating and handling these wildcard and multi-name certs in a fully interoperable way, the problem will have been solved. But for the moment, I believe that this currently isn't the case: although, if there is a way to do this across all the currently-deployed browsers, I'd be interested to hear about it. -- Neil

Tim Starling wrote: Both methods have their own drawbacks and advantages. The problem with multi-name certs is all the other platforms: mobile phones and embedded web browsers, HTTP client libraries for Java/Python/Perl etc, bizarre things like man-in-the-middle HTTPS proxies (yes, they're out there)... until you've tried it, you don't know if its going to work, unlike using IP addresses to select the cert to be sent, which is known to work for all HTTPS-speaking clients. Of course, this doesn't mean you shouldn't do the multi-name cert thing; the wiki page suggests it should just work for all the major browsers, which implies that it should just work for something like 99% of all web users, just that it's going to need a lot of testing before it goes live, and then providing fallback to plain HTTP login for all clients which cannot handle this, most probably based on user-agent strings. -- Neil

Brion Vibber wrote: 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.