Re: wiki password
On Wed, Oct 27, 2010 at 04:21:45PM -0400, David N Murray wrote: On Oct 27, Tomas Hlavaty scribed: not sure if I understand it well but it seems to me that your hash becomes the password. In other words, if I find out the hash, I can log in (e.g. using my own client). Yes, I suppose, but the only way I see you getting the hash is: a) steal the database b) be a MITM over https (I don't do passwords over http when I design a site) c) browser exploit? not sure if that's possible Or simply create an account for yourself and analyze the encryption of your own password in the client. As the client needs the full information, including the encryption keys, you might crack it easily. -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
Hi Alex, yes, it's all about prevention;-) Storing plain text passwords is no prevention. But encrypting them creates only an illusion of safety. I didn't suggest encrypting them but using hash+salt! We should not waste our time on irrelevant issues. Whether passwords are encrypted locally or not is just a matter of cosmetics. I strongly disagree with this statement. And again, I didn't suggest encrypting passwords! What are we discussing here? What really counts are two issues: 1. The _whole_ database must be safe from any external access 2. We must _trust_ the administrator(s) of the machine 1) the whole discussion about acknowledging that some data are more confidential then other. You obviously don't think so. 2) is usually enforced by legal means and/or by reputation. There is no technical solution to this. It is ridiculous if we talk about allowing changing passwords and/or sending them via unencrypted mails, and at the same time make so much fuss about hiding them within the machine. Again, I am strongly against sending passwords via e-mail. If you don't store the passwords in the first place, there is no way to send them obviously. Instead, all effort should go into protecting the system itself. There are many ways and different situations where the system should be protected. From the point somewhere gets hold of your database your system is completely unprotected. And confidential databases leak all the time. The thing I suggested would give protection to passwords even if somebody got hold of the database. Cheers, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
Hi Alex, I personally have bad experience with people storing passwords in plain text. Technically it might not be an issue (after all I think the wiki doesn't need passwords at all) but it is certainly one of those warning Thanks as ever for your input, but your argumentation is quite inconsistent. While you stress the rather cosmetic issue of whether passwords are stored (non)encrypted in the db, you suggest using no passwords at all for the wiki. This is a very bad idea. If you take a closer look at the wiki, you see that it uses a role/permission system. We have admin users who can do anything, and member users with limited rights. As anybody in the world who finds his way to this wiki can automatically become a member, he could easily obtain administrative rights if there were no passwords, with the result that he could completely manipulate all data, including the editing history. It is consistent. My point is that there is no need for password in the case of the wiki (see the Ward's Wiki; and if you can change history in your wiki then your revisioning is likely broken by desing in such scenario). However, as you insist on using the passwords, I'm suggesting doing it a bit better then storing them in plain text. But here we were talking about storing plain text passwords in a protected database, which would get compromised only if the whole database got into evil hands, which in turn has to be avoided for more important reasons than just the passwords (in the general case). The database is protected only until it becomes unprotected, e.g. somebody untrusted gets hold of it. This is not a time-traveling scenario, these things happen. Cheers, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
Hi Tomas, But encrypting them creates only an illusion of safety. I didn't suggest encrypting them but using hash+salt! Yes, of course. That's nitpicking. Please excuse that I didn't pay attention to the terminology. 1) the whole discussion about acknowledging that some data are more confidential then other. You obviously don't think so. No, precisely because normally the _data_ in a database are much more valuable than the passwords. It is ridiculous if we talk about allowing changing passwords and/or sending them via unencrypted mails, and at the same time make so much fuss about hiding them within the machine. Again, I am strongly against sending passwords via e-mail. If you don't store the passwords in the first place, there is no way to send them obviously. You should read the discussion in this thread carefully. We had suggestions to generate short-term passwords and send them by mail. protected. From the point somewhere gets hold of your database your system is completely unprotected. And confidential databases leak all Again: If somebody gets hold of the database, everything is lost. This is what must be avoided, and not eyewashing by pretending a false security. And confidential databases leak all the time. Really?! Probably because they relied on their encrypted (sorry: hashed!) passwords :-D The thing I suggested would give protection to passwords even if somebody got hold of the database. See above. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
Hi Dave, It seems to have been lost somewhere along the way, but my original email indicated I use a one-way hash of the password (a la crypt(), but there Yes, I know. As Tomas already noticed, I mixed up encryption and hashing, though I'm well aware of the differences, and also used MD5 in my propsed solutions (could be easily substituted with other algorithms). Sorry for the confusion! Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
