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
Re: wiki password
Hi Alex, You see the advantage in the current case: After Javier forgot his password (and started this thread) I sent him his old password in an encrypted mail. This is a big flaw. You should not be able ever to find out his password. Cheers, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
Hi Tomas, This is a big flaw. You should not be able ever to find out his password. Why not? Nobody could stop me anyway. I could trace the program during execution, for example, to get the passwords. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
On Wed, Oct 27, 2010 at 2:54 PM, Alexander Burger a...@software-lab.de wro= te: Hi Tomas, This is a big flaw. =A0You should not be able ever to find out his password. Why not? Nobody could stop me anyway. I could trace the program during execution, for example, to get the passwords. oh yes! :D /e -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
On Oct 27, Alexander Burger scribed: Why not? Nobody could stop me anyway. I could trace the program during execution, for example, to get the passwords. Pardon me for jumping in (short time lurker; reading the archives alot). In general, I've always designed systems with passwords stored in a database as a one-way hash so that if the database gets compromised, you're not giving up users' passwords (it's a PITA to tell everyone to change their password). I encrypt the passwords in the browser (using the same algorithm) and always transmit an encrypted password. There's no place to peek. I provide a one-time link to a password reset page if they forgot their password. That's sent to the email on file (which they gave me). hth, Dave -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
Hello all, On Wednesday 27 October 2010 16:15:35 Dave wrote: (...) I encrypt the passwords in the browser (using the same algorithm) and always transmit an encrypted password. There's no place to peek. (...) I believe you mean `I take a hash of password and some salt in the browser and always transmit the hash' (or better, `I use HMAC')... Otherwise the owner of the process could still trace it to recover the passwords, coudn't he? -- dexen deVries ``One can't proceed from the informal to the formal by formal means.'' -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
Hi Alex and Edwin, This is a big flaw. =A0You should not be able ever to find out his password. Why not? Nobody could stop me anyway. I could trace the program during execution, for example, to get the passwords. oh yes! :D So you don't lock your house because it's impossible to make it thieve-proof? Or, why do you lock your house when it so easy to break in anyway? Your lock most likely works because there is so little incentive to get in. Some time ago I saw a BBC documentary about how rich people live in Moscow. One of their main criteria was how many guards with Kalashnikov the place had:-o Maybe ever was too strong word I used because it's impossible as you quickly pointed out. However, securing login is not black and white but rather many shades of gray. If you use plain text passwords and somebody gets hold of the data, he has all those passwords available for all users instantly. If you don't store the passwords, you limit significantly the places and moments where the passwords can leak. Also, not all of them leak at the same time together instantly but only one or a few might get compromised (e.g. if you trace the program during execution in order to spy on somebody's password). In other words, there is a huge difference between getting all passwords in one go the moment I get access to the machine, and between getting passwords gradually as people log in while I'm having access to the machine. And it's rather easy to fix. 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 signs telling me get ready for trouble with these guys (http://i.imgur.com/xZW77.png ). And this issue pops up all the time, e.g. today on reddit http://www.reddit.com/r/programming/comments/dwkzr/is_it_industry_common_practice_to_send_plaintext/ Cheers, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
Hi David, In general, I've always designed systems with passwords stored in a database as a one-way hash so that if the database gets compromised, you're not giving up users' passwords (it's a PITA to tell everyone to change their password). I encrypt the passwords in the browser (using the same algorithm) and always transmit an encrypted password. There's no place to peek. I provide a one-time link to a password reset page if they forgot their password. That's sent to the email on file (which they gave me). 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). Cheers, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
Hi Alex, This is a big flaw. You should not be able ever to find out his password. Why not? I could trace the program during execution, for example, to get the passwords. in a sense you are doing exactly this. And your trace log of plain text passwords goes to the picolisp database. Nobody could stop me anyway. What do you mean? You are the provider of the service! I guess there is a missunderstanding somewhere. Cheers, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
On Wed, Oct 27, 2010 at 08:50:51PM +0200, Tomas Hlavaty wrote: Nobody could stop me anyway. What do you mean? You are the provider of the service! I guess there is a missunderstanding somewhere. I mean as I'm the admin of that machine, I cannot be stopped to access the passwords. Even if they were encrypted, I could run a brute force attack. -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
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 Dave -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
Hi Tomas, If you use plain text passwords and somebody gets hold of the data, he has all those passwords available for all users instantly. If you don't Well - in a commercial application, not in the Wiki - if he gets hold of the data, then we don't need to worry about the passwords any more :-D Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
Hi Alex, Nobody could stop me anyway. What do you mean? You are the provider of the service! I guess there is a missunderstanding somewhere. I mean as I'm the admin of that machine, I cannot be stopped to access the passwords. You are the provider of the service and as such users trust that you handle their data reasonably well in the first place. If that assumption doesn't hold, there is no point in talking about securing anything. We are talking here about untrusted 3rd parties, right? Even if they were encrypted, I could run a brute force attack. How viable that would be depends on the quality of the encryption. Also note that storing hash+salt is different from storing encrypted password. And yes, you can run a brute force attack. _Anyone_ can run it actually even without having access to the login data (e.g. trying out different passwords in the login form). If you have the data locally, it just makes it faster to get the feedback. How successful such attempt is depends mainly on the quality of the user's password. In other words, plain text password doesn't need any effort, poorly encrypted password can be decrypted using something significantly more efficient than brute force. Brute force is the least efficient method. The idea there is that you'd have to spend significant effort to get to the passwords. Cheers, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
Hi David, 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 all these things happen in the real world. That's why securing login is hard and confidential stuff leaks all the time. You could address your current assumptions by, for example: ad a) use hash+salt server side ad b) not sure;-) ad c) don't use javascript MITM is probably hardest to address but a) shouldn't take much effort and c) depends on your application I guess. I don't do passwords over http when I design a site Does it mean that you do everything over https? Or login only? How do you handle sessions then? In url (like the standard picolisp GUI), in query parameter (using POST) or a cookie? Cheers, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
Hi Alex, If you use plain text passwords and somebody gets hold of the data, he has all those passwords available for all users instantly. If you don't Well - in a commercial application, not in the Wiki - if he gets hold of the data, then we don't need to worry about the passwords any more :-D yes, it's all about prevention;-) Storing plain text passwords is no prevention. Cheers, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
Hi Tomas, 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. signs telling me get ready for trouble with these guys (http://i.imgur.com/xZW77.png ). And this issue pops up all the time, e.g. today on reddit http://www.reddit.com/r/programming/comments/dwkzr/is_it_industry_common_practice_to_send_plaintext/ Different issues again. I objected in one of the first posts to this thread to sending passwords in unencrypted mails. 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). Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
Hi all! I'm fully agree with Alex, in this active discussion about passwords they sometimes forget about data itself :) ... 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). Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
On Wed, Oct 27, 2010 at 11:29:46PM +0200, Tomas Hlavaty wrote: Well - in a commercial application, not in the Wiki - if he gets hold of the data, then we don't need to worry about the passwords any more :-D yes, it's all about prevention;-) Storing plain text passwords is no prevention. But encrypting them creates only an illusion of safety. We should not waste our time on irrelevant issues. Whether passwords are encrypted locally or not is just a matter of cosmetics. 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 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. Instead, all effort should go into protecting the system itself. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
On Sat, Oct 23, 2010 at 12:18:45AM +0200, Javier wrote: Alex, please add a feature to reset the password, as I don't remember Thinking about it: What would be the best way? -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
On Tuesday 26 October 2010 14:31:17 you wrote: On Sat, Oct 23, 2010 at 12:18:45AM +0200, Javier wrote: Alex, please add a feature to reset the password, as I don't remember Thinking about it: What would be the best way? A rather popular aggregator known as Hacker News is using manual password reset method. You mail the site owner (Paul Graham) and he enables password reset functionality in your account (for a period of time) and mails you back with a link to reset the passwod. Worked a-OK for me, at least... -- dexen deVries ``One can't proceed from the informal to the formal by formal means.'' -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
El Tue, 26 Oct 2010 14:31:17 +0200 Alexander Burger a...@software-lab.de escribi=C3=B3: On Sat, Oct 23, 2010 at 12:18:45AM +0200, Javier wrote: Alex, please add a feature to reset the password, as I don't remember =20 Thinking about it: What would be the best way? Try this: 1. When the user presses reset pass the button on a valid user, generate a random password. 2. Store it in a special field in the User object (rpass?) along with the date of which that random pass was generated (rdate?) 3. Send it to the user in an email like this: Subject: Password reset for user (username) at (name-of-the-site) Someone requested a password reset for your account at (name-of-the-site), if you indeed want to reset your password, please log in with the following information: =09 Username: (username) Password: (rpass) If you don't want to change your password now, just ignore this email, the above credentials will expire in 24 hours, or the next time you log in normally. 4. Modify the login process in the following way: * First check for the stored password as usual, if it's valid, just log in normally, and wipe rpass and rdate if they exist. * If the regular pass fails, check whether rpass is not null, and rdate is not more than one day in the past. If the password matches, log in the user and take him/her to the password change form. I think the above procedure should be acceptably easy to use, implement and secure. Cheers, Jos=C3=A9 -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
El Tue, 26 Oct 2010 16:57:10 +0200 Alexander Burger a...@software-lab.de escribi=C3=B3: Hi Jos=C3=A9, =20 1. When the user presses reset pass the button on a valid user, generate a random password. 2. Store it in a special field in the User object (rpass?) along with the date of which that random pass was generated (rdate?) 3. Send it to the user in an email like this: Subject: Password reset for user (username) at (name-of-the-site) ... =20 Thanks, this sounds reasonable. =20 The only problem I see is sending the new password in an unencrypted email. Shouldn't be a big risk, I suppose. Otherwise, we could extend the user account so that everyone can deposit his public key, and enable this password reset functionality only for people who have done so. =20 Cheers, - Alex Well many sites use this scheme, some with special links and such, the risk is greatly disminished though because the user just needs to log in to render those credentials invalid. -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
El Wed, 27 Oct 2010 01:00:38 +0800 Boh Yap bhy...@gmail.com escribi=C3=B3: hi, =20 send 2 emails, the 1st informing that passwd reset is activated and a following email will contain the temp. passwd. =20 then send the passwd in the 2nd email. And if the 2nd email does not mention an acct name, then its reasonably safe. =20 That hurts usability, besides, if someone is logging your email you're in trouble anyway. Most sites send an special link to activate the account reset, that is at most as safe as the method i detailed, and mine isn't significantly harder to use, and it's easier to implement! Also note that the random password is not permanent, it loses validity after certain time (i suggested 24 hours, but you can make it as little as 1 hour or a few minutes if you're paranoid) OR if you log in (be it with your normal password or after using the reset), that way abuse of the feature is less problematic on active accounts (the ones that are most worth probably, anyway). You can also introduce blocks to the button if it presents a problem (for example, you can only request a reset every 2 days). But, really, only add that kind of complexity if abuse proves to be a problem, no need to overengineer it :3 Cheers, Jos=C3=A9 -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
Hi Alex, 1. When the user presses reset pass the button on a valid user, generate a random password. 2. Store it in a special field in the User object (rpass?) along with the date of which that random pass was generated (rdate?) 3. Send it to the user in an email like this: Subject: Password reset for user (username) at (name-of-the-site) ... The only problem I see is sending the new password in an unencrypted email. From my experience, I consider generating a password and sending it in an email very bad. Happened to me once, when I set-up an account with quite big VPS provider and they did this. I sent them an email complaining about it and they said it was standard practice and that I shouldn't worry. Only after two weeks after I got the hosting with them, they got hacked and all their servers wiped out. A lot of people weren't happy. On the other hand, as far as I remember, the standard picolisp way of storing passwords in plain text and even sending them to the user editing dialog is even worse. I would suggest changing the standard picolisp password handling completely. Use bcrypt and store only a hash and salt. Never send and display the password anywhere, and for forgotten passwords use a simple validation sequence. You can try something like that at http://logand.com/sw/ondoc/index.html after Sing up and then Change password. The only way I can see this to be secured further would be to use https. Cheers, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: wiki password
Hi Tomas, On the other hand, as far as I remember, the standard picolisp way of storing passwords in plain text and even sending them to the user editing dialog is even worse. No, this is not the case! The passwords do not go to the GUI, and never leave the server. Yes, they are stored in plain text in the DB. This is not a security problem, because if an aggressor manages to read the DB directly, he got control anyway. It would be a matter of changing just two lines to store them in a hashed form. I decided not to do that for this application. You see the advantage in the current case: After Javier forgot his password (and started this thread) I sent him his old password in an encrypted mail. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
