On Mon, 2005-06-06 at 10:36, bruce wrote: > and matt.. now you see the issue that i've been dealing with... > > my bad for not clarifying it earlier.. the ssl aspect helps, but it still > doesn't get to the issue of allowing someone to 'know' or be extremely > certain, that the site they're on, is the 'right' site for the url that > they're trying to obtain... > Develop a better user. :) > on a similar tip. if you lose your password.. what's a secure way to get the > password. the current method (of course) is to send you a new password via > email.. assuming that you know your username. but given the fact that email > is text, and could easily be sniffed, is there another/better way.. (and > let's not get into public/private encryption!!) > Setting aside encryption and using email to send a new temporary password, you are left with a couple of options. Setup your lost/reset password process to have users call via phone to a help desk. You will need to have on file a set of questions that attempt to authentic the person calling as the user requesting the password reset. But being totally paranoid can you really be user the person on the other end of the phone is who they say they are? :) If a user requests password reset via a web page or via email you use postal service or fedex to send a new password to address on file for that user. Again being totally paranoid can you trust the postal service or fedex to get letter to the right destination without someone intercepting it? :) Of course such a system should not have both the user id and the password or any other identifying information other than the temporary password. You could combine this with a process of sending the user a temp password but require them to call the help desk again to enable the temp password with another round of attempting to authenticate the user over the phone. To complicated and costly. :) Use a secure ID token to generate passwords so there is no static password for the user. This has the benefit of two factor authentication, user must know something (partial password or pin number) and have something (token) before they can log in. Depending on the tokens used you will need to have a process to resync tokens occasionally with the backend server. You really need to step back and examine what it is you are trying to protect and the potential for it being compromised and what the most likely vector is for compromise. Most cases are going to be internal breakdowns in security, someone on the inside, rather than externally. -- Scot L. Harris webid@xxxxxxxxxx APL is a write-only language. I can write programs in APL, but I can't read any of them. -- Roy Keir
