Re: encrypt password for webservices
From: Alek Davis (alek_DOT_davis_AT_intel_DOT_com)
Date: 04/14/03
- Next message: Ivan Medvedev [MS]: "Re: CodeAccessPermission.Demand() vs Assert()"
- Previous message: D. Niemeyer: "DirectoryServices Access Denied."
- In reply to: Etienne Charland: "Re: encrypt password for webservices"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Alek Davis" <alek_DOT_davis_AT_intel_DOT_com> Date: Mon, 14 Apr 2003 09:48:46 -0700
In 3) I did not mean actual threading, I understand what you are doing
there.
When you say about limitation of IIS/SLL (I assume it should be SSL)
security, I am not sure I understand. SSL has nothing to do with Windows
accounts or AD; you enable SSL by simply importing a valid certificate, and
you do not have to use it with Windows authentication; these are two
different aspects. SSL handles secure communication. Windows authentication
handles authorization (sounds like an oxymoron, it is more accurate to say
that it can be used by authorization). Anyway, it does have some
limitations, so your approach could be more flexible.
By the way, if you haven't done it, check out Microsoft's "Building Secure
ASP.NET Applications: Authentication, Authorization, and Secure
Communication" at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/ht
ml/secnetlpMSDN.asp or http://tinyurl.com/2ak1; it is really worth reading
(explained a lot of things for me).
-- Alek
"Etienne Charland" <mystery@golden.net> wrote in message
news:OsE1XshADHA.1156@TK2MSFTNGP12.phx.gbl...
> About IIS/SLL security, I see a major limitation: it uses windows accounts
> or Active Directory. You can't customize much.
>
> and about my security implementation...
> 3) Requests can be multi-threaded, and some requests can even be droped if
> we're using an UDP channel. I keep track of skipped sequence values, and
you
> can't skip too much at a time. So if the requests come in the wrong order,
> it will still work.
> 6) By associating a session with an IPrincipal object, I can make each
> remote call run under the client's credentials. I set the thread's
> CurrentPrincipal. Then, you can use what the framework offers to control
> access. This allows great flexibility and fluidity in the security, wich
> can't be done in IIS (or hardly).
>
> Etienne
>
> "Alek Davis" <alek_DOT_davis_AT_intel_DOT_com> wrote in message
> news:Ok0wmVJADHA.2368@TK2MSFTNGP10.phx.gbl...
> > OK, let me summarize how I understand it.
> >
> > (1) I assume that by SessionKey you mean session ID (I would call it
> > SessionID), which allows the server to find appropriate EncryptionKey
and
> > sequence number for each request. You do not use SessionKey for
> encryption.
> > (2) Client generates a session key and sends it to the server encrypted
> with
> > the server's public key, so server and client use the same symmetric key
> to
> > encrypt and decrypt passed data.
> > (3) You use sequence numbers to "single-thread" requests from a
particular
> > client to the server and to prevent malicious clients from injecting
their
> > own requests into this thread.
> > (4) Since client generated the session key and sent it to server
encrypted
> > with server's public key it is assumed that the key can be safe.
> > (5) By using sequence numbers, you eliminate the risk of replay attacks.
> > (6) Not sure what you need IPrincipal for.
> >
> > Well, you can certainly do this, although it looks very much like a
custom
> > implementation of SSL. Without knowing details of your application, it
is
> > hard to say what the drawbacks of this approach would be (e.g. as you
> said,
> > what happens when you run over 2^32, or when the server goes down, or if
a
> > server fails over). And I am not considering the risk of a malicious
> server
> > impersonator either. My take on this is that if someone on your intranet
> can
> > successfully and transparently compromise DNS/AD/network services,
you've
> > gotten bigger problems to worry about, but I may be wrong about it.
> >
> > For a Web-based application (ASP.NET/Web Service), I would be too lazy
to
> do
> > it your way, though. After all, why would I need to implement any extra
> > logic (i.e. keeping track of session keys and sequence numbers in
memory,
> > handling timeouts and invalid sequence numbers, etc), when SSL does
> > everything I need transparently to my application and without any effort
> on
> > my side? For a non-Web-based application, I don't know (never had to do
> > anything like this, except in an RPC-based application, for which I had
to
> > implement a similar logic instead of using built-in RPC-level
encryption).
> >
> > BTW, congratulations on getting a grip on security and encryption. I
know
> > what you mean: when you just get started, it seems very complex, but
once
> > you get to understand the basics, it is really not as bad (at least, for
> the
> > most common operations).
> >
> > -- Alek
> >
> > "Etienne Charland" <mystery@golden.net> wrote in message
> > news:uOvdhNIADHA.1692@TK2MSFTNGP12.phx.gbl...
> > > Of course, the server keeps session keys, and associated IPrincipal
> > object.
> > > Also those sessions timeout.
> > >
> > > The client and server can be configurated with specific RSA keys. If
> not,
> > > they will be generated at run-time, and the client asks the server for
> > it's
> > > public key. However, when the keys aren't explicitly specified, a fake
> > > server could grab all password hashes. I guess it's the same thing
with
> > SSL.
> > >
> > > During login, the client sends those values to the server:
> > > EncryptionKey (encrypted with RSA)
> > > Identity and password (encrypted with EncryptionKey)
> > > Initialization vector
> > >
> > > If the login succeed, the server returns SessionKey encrypted with
> > > EncryptionKey
> > >
> > > On each request, the client sends those informations:
> > > SessionKey (NOT encrypted. I don't want to use RSA on each call, and
the
> > > server needs something to identify the client before getting his
> session's
> > > encryption key)
> > > Sequence (see notes below)
> > > Uri (object name of the server, encrypted)
> > > Initialization vector
> > > Stream (encrypted with EncryptionKey)
> > >
> > > The response stream is simply encrypted with EncryptionKey
> > >
> > > If a request is not accepted, I return a message to the client.
> > >
> > >
> > > About the Sequence value on the requests, I need it to make sure each
> > > request is unique. Someone can encrypt his request with his
> EncryptionKey.
> > > If someone else takes that request and send it again, the SessionKey
> will
> > be
> > > valid, the stream will be correctly encrypted, the sequence will be
> > > decrypted, but the sequence value will be rejected since it have
already
> > > been processed, and the server keeps track of that sequence with the
> > > session. The hacker can't modify the sequence since he doesn't have
the
> > > encryption key.
> > >
> > > I don't see any problem with that (except that someone could do
> play-back
> > > attacks after the sequence comes back to already used values. That is,
> > after
> > > 2^32 queries have been done ;-) ) Does it work the same way in SSL?
> I've
> > > looked at many ways to do it, including using challenge/response, but
> this
> > > design is the only one that really works.
> > >
> > > (btw, when I started this, I knew nothing about cryptography! lol)
> > >
> > > Etienne Charland
> > >
> > > "Alek Davis" <alek_DOT_davis_AT_intel_DOT_com> wrote in message
> > > news:uNWyI2EADHA.2368@TK2MSFTNGP11.phx.gbl...
> > > > Hi Ettienne,
> > > >
> > > > I am not an expert in this area (SAL), but this is how I understand
> it.
> > > SAL
> > > > uses a (symmetric) session key to encrypt data. The good thing about
> > this
> > > > key is that it is defined for an HTTP connection between a single
> > instance
> > > > of a Web client and a Web server. So, if I grab someone else's data
> sent
> > > > over SAL and resend it on my behalf, the Web server will not be able
> to
> > > > decrypt them, because the Web server will use a different session
key,
> > > i.e.
> > > > a session key established for my connection, not the connection,
which
> > > data
> > > > I stole.
> > > >
> > > > I don't know the details of your solution, but I doubt that it is
> better
> > > > than SAL. Whenever you deal with passing sensitive data between
server
> > and
> > > > client, whether it is a Web application or a traditional
> client-server,
> > > the
> > > > only way to avoid a replay attack (or whatever it is called when a
> > hacker
> > > > simply resends stolen data), is by having a session between server
and
> a
> > > > client with a session-specific key. We spent a lot of time (well,
may
> be
> > > not
> > > > a lot, but at least some) trying to come up with an alternative, but
> > could
> > > > not. If you want to make your own solution, you will probably end up
> > > > implementing your version of SSL.
> > > >
> > > > If you give me more details, I can probably tell you the
> vulnerabilities
> > > of
> > > > your approach (feel free to e-mail me directly). The questions I
would
> > ask
> > > > are:
> > > >
> > > > (1) Which key do you use: public or symmetric?
> > > > (2) If you are using symmetric key, is it the same for all clients?
> > > > (3) How does the server keep track of the number of requests from a
> > > > particular client?
> > > > (4) What prevents a hacker to simply re-post the first post of the
> valid
> > > > query?
> > > >
> > > > Basically, I would like to know what you are protecting and how does
> > your
> > > > solution protects whatever you are protecting.
> > > >
> > > > -- Alek
> > > >
> > > > "Etienne Charland" <mystery@golden.net> wrote in message
> > > > news:e0csPG9$CHA.824@TK2MSFTNGP11.phx.gbl...
> > > > > Alek, do you know how SSL works to enforce security? What prevents
> > > someone
> > > > > to take an encrypted request and send it again? The server must
> accept
> > a
> > > > > particular query one, but not 2 times. When implementing my
remoting
> > > > > security solution, the only way I found is to have a counter that
> > > > > increments. The client encrypts the incremental value, and the
> server
> > > > > compare it to see if it's the good one. Does it works like that in
> > SSL,
> > > or
> > > > > does it have that flaw?
> > > > >
> > > > > Etienne
> > > > >
> > > > > "Alek Davis" <alek_DOT_davis_AT_intel_DOT_com> wrote in message
> > > > > news:OM6CHM7$CHA.3124@TK2MSFTNGP11.phx.gbl...
> > > > > > Mathew,
> > > > > >
> > > > > > Are you asking how to use encryption for secure communication or
> > > > storage?
> > > > > >
> > > > > > For secure communication use SSL. It is the only viable option
> which
> > > can
> > > > > > prevent a hacker from impersonating another user by simply
> grabbing
> > > > > someone
> > > > > > else's credentials, whether they are encrypted or not encrypted.
> > This
> > > > > means
> > > > > > that if you are passing credentials in every method, then every
> > method
> > > > > > should be called over SSL.
> > > > > >
> > > > > > For storage, do not use encryption, use hashing instead. If you
> only
> > > use
> > > > > > passwords to verify user's credentials, there is no need to
> decrypt
> > > > them.
> > > > > > Just store password hashes in the database and compare hashes
> (with
> > > > salt)
> > > > > > instead of plaintext values. This way you eliminate the hassles
> > > > associated
> > > > > > with key management. Check How To: Use Forms Authentication with
> SQL
> > > > > Server
> > > > > > 2000 (at
> > > > > >
> > > > >
> > > >
> > >
> >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/ht
> > > > > > ml/SecNetHT03.asp or http://tinyurl.com/99hg) for a nice
example.
> > > > > >
> > > > > > -- Alek
> > > > > >
> > > > > > "Mathew Michuta" <nektoinphx@yahoo.com> wrote in message
> > > > > > news:017201c2fedd$0725f1f0$a501280a@phx.gbl...
> > > > > > > I'll start by saying I've never done any encryption
> > > > > > > before. All my apps before now have been on an isolated
> > > > > > > network, with no real need.
> > > > > > >
> > > > > > > But now I need to use it. I have created webservices that
> > > > > > > return data to a vb.net windows forms application. It
> > > > > > > works fine receiving the username, password, and various
> > > > > > > other parameters, but now I need to add some sort of
> > > > > > > encryption so my passwords are not flying all over the
> > > > > > > internet in plain text.
> > > > > > >
> > > > > > > my ideal solution would be that the user logs into the vb
> > > > > > > app in florida using username and password. vb app
> > > > > > > encrypts username and password, requests authentication
> > > > > > > from my webservice in idaho, webservice receives string
> > > > > > > data, decrypts, compares to value stored in sql, and
> > > > > > > returns either 1(successful)/0(unsuccessful) or the hashed
> > > > > > > password to be used for all subsequent webservice data
> > > > > > > calls. I have set up all my webservices to require the
> > > > > > > username/password to be sent regardless of the function of
> > > > > > > the webmethod.
> > > > > > >
> > > > > > > My question is how do I do that? Are there any tutorials
> > > > > > > on how to use encryption in that manner? I'm assuming that
> > > > > > > I would not want to encrypt all data, due to performance
> > > > > > > issues on the server and client.
> > > > > > >
> > > > > > > Thanks in advance.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
- Next message: Ivan Medvedev [MS]: "Re: CodeAccessPermission.Demand() vs Assert()"
- Previous message: D. Niemeyer: "DirectoryServices Access Denied."
- In reply to: Etienne Charland: "Re: encrypt password for webservices"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
