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
