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
