[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Auth]Re: Auth digest, Vol 1 #38 - 7 msgs
From: |
David E. Raccah |
Subject: |
[Auth]Re: Auth digest, Vol 1 #38 - 7 msgs |
Date: |
Thu, 02 Aug 2001 17:21:40 -0700 |
Hello,
This is also my first listing on this list. I looked at your Single Logon
Proposal, and it looks great. However, I have some issues, which with a bit of
tweaking could be fixed.
Here are my issues:
1) Do not want to have a client software package on the client machine, as this
will not allow me to do single logon when I am using a kiosk, library, or
friend's machine.
2) Do not want to have my data stored locally, or with me via a disk. Yes,
your proposal stresses the fact that it does not care where the data is, but I
do not want to think about it, rather I want it available to me no matter where
I am, or what I am doing!
So what about this addition to your idea?
Instead of having some software on your machine that holds the password etc,
why not have a server that holds that data for you? The data on the server
would be encrypted with you public key, and you would pass your username and
private key to the server to un-encrypt your SIML file. So the steps are the
following:
(*NOTE* This step is extra, but I have no way around it, may need to think more
about it)
1) When you go to the first web site after starting your browser, click on the
link "Login Using SIML" (This is the extra step that I cannot get around).
2) This will re-direct you to the data server using an SSL connection and
prompt you with the authenticate login box. This will be your username and
private key.
3) The data server will then authenticate you.
4) If you are successful, it will encrypt your SIML with your favorite
website's public key and send it to your favorite web site, hashed with your
session id. Then you get redirected to your favorite website and from now on,
you will never have to retype in your private key, until you close your broswer.
5) If you are not successful in your authentication, then you will be notified
by your favorite web site.
Again from now as long as you have not closed your browser), you will only need
to click on the "Logon Using SIML" link at your favorite web site and you will
magically be entered into your favorite website. Because behind the scene you
are being redirected to the data server and the data server will ask your
browser for that private key which it has in memory and it will repackage your
SIML file encrypted with the next favorite web site's public key, so all is
secure. You the user see nothing after the first authentication except for
some redirects and the fact that you must do the extra step of clicking on the
"Use SIML Logon" link.
Note, this can be used when the user does not have the client installed, either
because the user does not want the software, or because the user cannot install
the software on this machine.
This way if the data server is attacked, the data would not be useful without
your private key. The data server would be managed by a private organization
(like MIT's Public Key database), which would be funded by the web sites that
want the users that have signed up for SIML access. The price would be just
enough to stay afloat, not to be profitable.
One more note, there is a way to use certificates when the certificate is not
on the machine. Verisign was working on accessing non-local certificates using
chaining, need to look at where that is again.
David
Original Message
------------------
Fernando Ipar wrote:
>
> This is my first post to the list, i've been meaning to ask this and now that
> > the subject has been brought up i'll take the chance. How hard would it be
> to
> implement the auth system using digital certificates along with username &
> password ?. I know pgp signatures can be used as an alternative, but i'm
> interested in using a PKI, giving any provider the ability to use it's users
> certificates for authentication (for it's own services and other dotgnu
> services).
> I have experience in financial institutions providing some services on the
> internet (account operations such as balances and transfers, credit card
> balance check, etc) and the use of digital certificates proved to be very
> usefull more than once (if you base your authentication solely on
> username/password, an internal leak could easly lead into a disaster, if you
> use digital certificates and your CA has reasonable levels of security it is
> much harder for any potential attacker to exploit your system).
>
> I would like to hear other's opinion on this matter, i know this probably
> isn't an important issue for the first release but it could be taken into
> account in the desing anyway.
>
> best regards,
> Fernando Ipar.
I agree, we should try and limit the complexity for a first
release. Can you see how the current framework can be
extended to support your ideas? If so, can you provide a
quick description. If not, how do we need to change the
framework to support your ideas.
Regards,
--
Albert Scherbinsky
Drop by at: http://members.home.net/alberts/
Convenient control of our personal information:
Single Login:
http://members.home.net/alberts/single.htm
Simple Interface Markup Language:
http://members.home.net/alberts/siml.htm
Personal Information Base XML
http://members.home.net/alberts/PIB.htm
- [Auth]Re: Auth digest, Vol 1 #38 - 7 msgs,
David E. Raccah <=