I have used AOL's OpenID or OpenAuth implementation on a project. It's
a pretty easy thing to use. I does however require the users to have
an AIM Screen Name. In my case this wasn't an issue.
LDAP is a very good option.
Another is to implement a challenge - response system using several
questions about information that only they would know or see
subtleties in. It is being used by banks and mortgage industry folks
to authenticate people. Using both predefined and user defined
questions that will be answered at registration. Then use a
combination of the predefined and user defined questions when a user
needs to reset their password. Often systems like this use data banks
of information on a person to build questions, but it can certainly be
created without such info.
Bryan
On 7/13/07, Cheyenne Throckmorton <[EMAIL PROTECTED]> wrote:
Fortunately, this system access and value of the data is not terribly
important. Basically just gives them an ability to upload a word document,
which we have trouble getting those users that can login to do.
I was merely just tossing the question out there in case there were any
creative ideas out there for handling this sort of a situation. At the same
time, I put on my Dean Saxe shield, since I was pretty sure he'd come into
the thread blasting, which is good. It wasn't nearly as bad as I had
imagined. However, I always appreciate the advice, especially for when
there may be a system that will have to have tighter security.
Has anyone implemented OpenID login functionality? I'm thinking that might
be a good way to provide an alternative login method to our sites, even
though I'm pretty sure 99% of our target audience will have no clue what
that means much less have an OpenID.
But basically, for this situation, its really a verbal authentication with
the information you have on the person, which means that asking secret
questions and other non-obvious cues for peoples accounts is probably a good
idea for future authentication systems.
On 7/13/07, Dean H. Saxe <[EMAIL PROTECTED]> wrote:
>
> Well, seriously.
>
>
> How are you going to identify the account uniquely (to the extent that
email really can do that)? Unless you have an alternative identification
system, you're really SOL.
>
>
> Is there other contact information you can use to communicate with this
person? Another way to identify him or her to reset the password? What is
the value of the data? What is the value of the data to someone else? Can
you afford to reset the password for someone who you cannot identify as the
original owner of the account?
>
>
> This is a serious challenge in any system which depends on an address as
an identifier that may not exist tomorrow.
>
>
> -dhs
>
>
>
>
>
> Dean H. Saxe, CISSP, CEH
> [EMAIL PROTECTED]
> "[T]he people can always be brought to the bidding of the leaders. This is
easy. All you have to do is to tell them they are being attacked, and
denounce the pacifists for lack of patriotism and exposing the country to
danger. It works the same in every country."
> --Hermann Goering, Hitler's Reich-Marshall at the Nuremberg Trials
>
>
>
>
> On Jul 13, 2007, at 5:04 PM, AppDeveloper wrote:
>
> Could you be more pedagogical, Dean?
>
>
> On 7/13/07, Dean H. Saxe <[EMAIL PROTECTED]> wrote:
> >
> > In that case, your clients are screwed.
> >
> >
> > Happy to help!
> >
> >
> > -dhs
> >
> >
> > (FWIW, Basic AuthN is HORRIBLY insecure and should be avoided at all
cost.)
> >
> >
> >
> >
> >
> >
> >
> >
> > Dean H. Saxe, CISSP, CEH
> > [EMAIL PROTECTED]
> > "What is objectionable, what is dangerous about extremists is not that
they are extreme, but that they are intolerant."
> > -- Robert F. Kennedy, 1964
> >
> >
> >
> >
> > On Jul 13, 2007, at 4:38 PM, Cheyenne Throckmorton wrote:
> >
> >
> > In most of our applications that we run our basic authentication is to
have them provide their email address as a username and then a password.
> >
> > We store that password hashed with salt onto our databases, and have no
real way of knowing what it is. If a user forgets their password then they
have the system email them a link with a URL with a GUID variable that takes
them to a page where they can reset their password to whatever they want
again, and again only its hash is stored in our databases.
> >
> > Now this is all fine and dandy, except what happens if this person both
forgets their password and changes email, say they changed jobs and no
longer have access to the old email, how do you now authenticate this
person?
> >
> > Currently, we don't have any secret questions or the like set up, but is
that the only way.
> >
> > Just curious on some of your ideas out there on how you do
authentication, especially in the case of changed email and forgotten
password.
> >
> > Cheyenne
> >
-------------------------------------------------------------
> > Annual Sponsor - Figleaf Software
> >
> > To unsubscribe from this list, manage your profile @
> > http://www.acfug.org?fa=login.edituserform
> >
> > For more info, see http://www.acfug.org/mailinglists
> > Archive @
http://www.mail-archive.com/discussion%40acfug.org/
> > List hosted by FusionLink
> >
-------------------------------------------------------------
> >
>
>
>
-------------------------------------------------------------
> Annual Sponsor - Figleaf Software
>
> To unsubscribe from this list, manage your profile @
> http://www.acfug.org?fa=login.edituserform
>
> For more info, see http://www.acfug.org/mailinglists
> Archive @
http://www.mail-archive.com/discussion%40acfug.org/
> List hosted by FusionLink
>
-------------------------------------------------------------
>
-------------------------------------------------------------
Annual Sponsor - Figleaf Software
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @
http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------
-------------------------------------------------------------
Annual Sponsor FigLeaf Software - http://www.figleaf.com
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------
