Re: encrypt password for webservices

• Previous message: Shel Blauman [MSFT]: "Re: UnauthorizedAccessException Help"
• In reply to: Alek Davis: "Re: encrypt password for webservices"
• Next in thread: Alek Davis: "Re: encrypt password for webservices"
• Reply: Alek Davis: "Re: encrypt password for webservices"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: "Etienne Charland" <mystery@golden.net>
Date: Sun, 13 Apr 2003 20:16:27 -0400

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.
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

• Previous message: Shel Blauman [MSFT]: "Re: UnauthorizedAccessException Help"
• In reply to: Alek Davis: "Re: encrypt password for webservices"
• Next in thread: Alek Davis: "Re: encrypt password for webservices"
• Reply: Alek Davis: "Re: encrypt password for webservices"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]