Re: Sending passwords securely over the Internet
From: Alek Davis (alek_xDOTx_davis_xATx_intel_xDOTx_com)
Date: 02/09/04
- Next message: Marcos Rosa: "Public Key"
- Previous message: Guangxi Wu: "Re: XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1"
- In reply to: DalePres: "Sending passwords securely over the Internet"
- Next in thread: DalePres: "Re: Sending passwords securely over the Internet"
- Reply: DalePres: "Re: Sending passwords securely over the Internet"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 9 Feb 2004 14:09:46 -0800
Dale,
Your question touches several security aspects and does not have enough info
to allow someone to give you "do it this way" recommendations (and I don't
think a newsgroup is a proper venue for answering "what should my
application architecture look like" types of questions), but let me offer my
2 cents.
First of all, you have to distinguish between security risks related to data
communication, storage, and verification. I mean, the way you build a data
exchange mechanism has little effect on how you want to store your data and
vise versa. Let's talk about the fundamentals. What do you need the user
password for? Since you already hash it, I assume that you use it for
authentication purposes only (which is good and using the salt value is also
a good decision). Now, is your app runs on a Windows domain and are your
users Windows domain users? If this is the case, in some situations
(depending what your application architecture looks like) you may not even
need passwords, and may be able to extract user's credentials at runtime
(via RPC impersonation mechanism). There may be cases, where this will not
work, so let's assume you cannot use Windows credentials, so you need to do
whatever you do now. This brings us to the secure communication issue (when
the client app send user password to the server). This is what SSL is
designed for. If you cannot use SSL out of the box (say, your app is not Web
based), you can implement your own key exchange mechanism. It is not too
complex, but you need to prevent the replay attacks (i.e. malicious user
stealing the packets sent by the good user), which is not rocket science
either. Assuming that you take care of the communication, you must be OK, at
least it looks like you are using commonly accepted security practices (and
you should be commended for this).
Alek
"DalePres" <don-t-spa-m-me@lea-ve-me-a-lone--.com> wrote in message
news:et9tGxO7DHA.1632@TK2MSFTNGP12.phx.gbl...
> I am looking for some feed back on what is considered to be a safe and
> secure method for sending passwords in a Windows Forms based client/server
> application.
>
> I tried sending this earlier today on the MSDN Newsgroups web viewer but
it
> didn't seem to go through. If it's here twice later, accept my apologies.
> The time lag between when I submitted the question earlier and now
explains
> some technical differences between the two posts. I have already added a
> "seed" to the password before storing the hash in order to make sure that
no
> two passwords are stored the same, even if the plain text passwords are
the
> same.
>
> What I am doing now is:
>
> User information is stored in a SQL Server table on the server. This
> includes a user name and a unique user number. The user password is
combined
> with the user number and then hashed using SHA512. This hash is converted
> to a BASE64 string. So the stored information used for login is the
> username, the usernumber, and the BASE64 string of the SHA512 hash of
> (userNumber.ToString() + passWord).
>
> When a user logs in, they enter their password and user number in a dialog
> box. These are combined, hashed, and then converted to a BASE64 string
for
> transport over the internet.
>
> The server retrieves the BASE64 string from the database for the supplied
> user name and compares it to the string received from the client. If they
> match, a success message is sent to the user and communications can begin.
>
> My question is, does this constitute a secure login scenario? Is there
> something else I should be doing, without having to use costly systems
like
> certificates and smartcards, to be as certain as possible of the identity
of
> the login?
>
> Thanks,
>
> Dale Preston
>
>
- Next message: Marcos Rosa: "Public Key"
- Previous message: Guangxi Wu: "Re: XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1"
- In reply to: DalePres: "Sending passwords securely over the Internet"
- Next in thread: DalePres: "Re: Sending passwords securely over the Internet"
- Reply: DalePres: "Re: Sending passwords securely over the Internet"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
