how can you verify that the site you get is not a fake?

[Scot L. Harris]

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 at cfl.rr.com

APL is a write-only language.  I can write programs in APL, but I can't
read any of them.
		-- Roy Keir