Hi,

I'm creating a web based database. The users of the database will
complete a login form with User Name and Password.

Many browsers offer the user the option of storing their login
details. For example: IE asks if you want to store the login details
when you click the submit button.

I need to know if there anything I can do when I create the login page
(which will be generated by a Perl program) which will either prevent
the browser from offering this option or prevent the user from
accepting it.

Any ideas welcome!

Nigel

"Danish" <nigel@bouteyres.com> wrote in message
news:81ad96bf-f485-470a-8e97-8708483a8fdb@i29g2000prf.googlegroups.com...
> Hi,
>
> I'm creating a web based database. The users of the database will
> complete a login form with User Name and Password.
>
> Many browsers offer the user the option of storing their login
> details. For example: IE asks if you want to store the login details
> when you click the submit button.
>
> I need to know if there anything I can do when I create the login page
> (which will be generated by a Perl program) which will either prevent
> the browser from offering this option or prevent the user from
> accepting it.

You cannot control how your viewers use their browser options.

--
Richard.

Danish wrote:

> Many browsers offer the user the option of storing their login details.
> For example: IE asks if you want to store the login details when you
> click the submit button.
>
> I need to know if there anything I can do when I create the login page
> (which will be generated by a Perl program) which will either prevent
> the browser from offering this option or prevent the user from accepting
> it.

Firstly, think very carefully before attempting to do such a thing.
Browsers offer this facility because people like this facility. If you
attempt to disable it, chances are you'll just annoy your visitors. If
you're not a bank, or offering access to people's medical records, or
safeguarding the launch codes for some nation's nuclear missiles, then
it's probably better to just live with autocomplete -- don't try to work
your way around it.

Bear in mind that having working autocomplete allows the user to choose
very long and hard-to-remember passwords, safe in the knowledge that they
don't need to type them very often. If you disable autocomplete, users may
be tempted to choose shorter, easier to type passwords. So disabling
autocomplete could paradoxically make your site *less* secure!

If you have thought about this, and are really sure you want to disable
autocomplete, then the trick is to add 'autocomplete="off"' to all the
<input> elements for which you wish to disable the feature. This is a
proprietary Microsoft attribute, so it will make your HTML invalid, but it
should do the trick most of the time -- and not just for Internet
Explorer, as most other browser vendors have adopted it too.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 15 days, 22:44.]

Mince & Dumplings
http://tobyinkster.co.uk/blog/2008/0...nce-dumplings/

Danish <nigel@bouteyres.com> wrote:

> Hi,
>
> I'm creating a web based database. The users of the database will
> complete a login form with User Name and Password.
>
> Many browsers offer the user the option of storing their login
> details. For example: IE asks if you want to store the login details
> when you click the submit button.
>
> I need to know if there anything I can do when I create the login page
> (which will be generated by a Perl program) which will either prevent
> the browser from offering this option or prevent the user from
> accepting it.
>
> Any ideas welcome!

Besides the good advice by Toby:

* check passwords if they are weak or strong
* expire passwords after a given time

--
John Bokma http://johnbokma.com/

Danish wrote:
> Hi,
>
> I'm creating a web based database. The users of the database will
> complete a login form with User Name and Password.
>
> Many browsers offer the user the option of storing their login
> details. For example: IE asks if you want to store the login details
> when you click the submit button.
>
> I need to know if there anything I can do when I create the login page
> (which will be generated by a Perl program) which will either prevent
> the browser from offering this option or prevent the user from
> accepting it.
>
> Any ideas welcome!
>
> Nigel

A site that did that to me I would never use again, but regardless,
there are ways around it anyway.

--
"Yah know I hate it when forces gather in ma' fringe..." - Sheogorath

"Daytime television sucked 20 years ago,
and it still sucks today!" - Marc Bissonette

Toby A Inkster wrote:
>
> Firstly, think very carefully before attempting to do such a thing.
> Browsers offer this facility because people like this facility. If you
> attempt to disable it, chances are you'll just annoy your visitors. If
> you're not a bank, or offering access to people's medical records, or
> safeguarding the launch codes for some nation's nuclear missiles, then
> it's probably better to just live with autocomplete -- don't try to work
> your way around it.
>
> Bear in mind that having working autocomplete allows the user to choose
> very long and hard-to-remember passwords, safe in the knowledge that they
> don't need to type them very often. If you disable autocomplete, users may
> be tempted to choose shorter, easier to type passwords. So disabling
> autocomplete could paradoxically make your site *less* secure!
>
> If you have thought about this, and are really sure you want to disable
> autocomplete, then the trick is to add 'autocomplete="off"' to all the
> <input> elements for which you wish to disable the feature. This is a
> proprietary Microsoft attribute, so it will make your HTML invalid, but it
> should do the trick most of the time -- and not just for Internet
> Explorer, as most other browser vendors have adopted it too.
>
Not tested, but pretty sure it would work: Add a generated timestamp or
random string to the input name:
<input type="password" name="password_74234915">

That said, I completely agree with the other comments - I probably
wouldn't bother to use the site. It's a pretty sure-fire way to lose users.

On Feb 14, 8:01pm, WindsorFox <darkshado...@gmail.com> wrote:
> Danish wrote:
> > Hi,
>
> > I'm creating a web based database. The users of the database will
> > complete a login form with User Name and Password.
>
> > Many browsers offer the user the option of storing their login
> > details. For example: IE asks if you want to store the login details
> > when you click the submit button.
>
> > I need to know if there anything I can do when I create the login page
> > (which will be generated by a Perl program) which will either prevent
> > the browser from offering this option or prevent the user from
> > accepting it.
>
> > Any ideas welcome!
>
> > Nigel
>
> A site that did that to me I would never use again, but regardless,
> there are ways around it anyway.
>
> --
> "Yah know I hate it when forces gather in ma' fringe..." - Sheogorath
>
> "Daytime television sucked 20 years ago,
> and it still sucks today!" - Marc Bissonette- Hide quoted text -
>
> - Show quoted text -

Hi all,

Thanks for the various advice. I should have made clear that the site
I'm creating is for use only by a company's employees (so they don't
have the choice about whether to use it or not), that they may be
accessing the data from 'public' computers and that the data stored is
of a sensitive nature so security is of high importance.

I take the point about autocomplete making it easier for visitors to
use complex passwords. I already have in mind to expire passwords
after a set period and to enforce a mix of alphabetic and numeric
characters and a minimum length.

Thanks again,

Nigel

On Feb 14, 8:59pm, Tony <nos...@example.com> wrote:
> Toby A Inkster wrote:
>
> > Firstly, think very carefully before attempting to do such a thing.
> > Browsers offer this facility because people like this facility. If you
> > attempt to disable it, chances are you'll just annoy your visitors. If
> > you're not a bank, or offering access to people's medical records, or
> > safeguarding the launch codes for some nation's nuclear missiles, then
> > it's probably better to just live with autocomplete -- don't try to work
> > your way around it.
>
> > Bear in mind that having working autocomplete allows the user to choose
> > very long and hard-to-remember passwords, safe in the knowledge that they
> > don't need to type them very often. If you disable autocomplete, users may
> > be tempted to choose shorter, easier to type passwords. So disabling
> > autocomplete could paradoxically make your site *less* secure!
>
> > If you have thought about this, and are really sure you want to disable
> > autocomplete, then the trick is to add 'autocomplete="off"' to all the
> > <input> elements for which you wish to disable the feature. This is a
> > proprietary Microsoft attribute, so it will make your HTML invalid, but it
> > should do the trick most of the time -- and not just for Internet
> > Explorer, as most other browser vendors have adopted it too.
>
> Not tested, but pretty sure it would work: Add a generated timestamp or
> random string to the input name:
> <input type="password" name="password_74234915">
>
> That said, I completely agree with the other comments - I probably
> wouldn't bother to use the site. It's a pretty sure-fire way to lose users..- Hide quoted text -
>
> - Show quoted text -

If I do end up taking this approach how would my program know what
field name to expect? Store the name in a ? Oh, I suppose a
hidden field with the name in it would do the trick. Or did you have
another solution in mind?

Danish wrote:
> On Feb 14, 8:01 pm, WindsorFox <darkshado...@gmail.com> wrote:
>> Danish wrote:
>>> Hi,
>>> I'm creating a web based database. The users of the database will
>>> complete a login form with User Name and Password.
>>> Many browsers offer the user the option of storing their login
>>> details. For example: IE asks if you want to store the login details
>>> when you click the submit button.
>>> I need to know if there anything I can do when I create the login page
>>> (which will be generated by a Perl program) which will either prevent
>>> the browser from offering this option or prevent the user from
>>> accepting it.
>>> Any ideas welcome!
>>> Nigel
>> A site that did that to me I would never use again, but regardless,
>> there are ways around it anyway.
>>
>> --
>> "Yah know I hate it when forces gather in ma' fringe..." - Sheogorath
>>
>> "Daytime television sucked 20 years ago,
>> and it still sucks today!" - Marc Bissonette- Hide quoted text -
>>
>> - Show quoted text -
>
> Hi all,
>
> Thanks for the various advice. I should have made clear that the site
> I'm creating is for use only by a company's employees (so they don't
> have the choice about whether to use it or not), that they may be
> accessing the data from 'public' computers and that the data stored is
> of a sensitive nature so security is of high importance.
>
> I take the point about autocomplete making it easier for visitors to
> use complex passwords. I already have in mind to expire passwords
> after a set period and to enforce a mix of alphabetic and numeric
> characters and a minimum length.
>
> Thanks again,
>
> Nigel
>
>
>

But that won't stop browsers from storing passwords on those public
computers. All it will do is keep the user from reusing the passwords.
The password can still be on the computer - and readable by an
administrator.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Feb 18, 12:59 pm, Danish wrote:
> I should have made clear that the site
> I'm creating is for use only by a company's employees (so they don't
> have the choice about whether to use it or not), that they may be
> accessing the data from 'public' computers and that the data stored is
> of a sensitive nature so security is of high importance.
>
> Nigel

Maybe use two passwords and a pre-decided simple algorithm.
For example after logging in with a first password like
password123 the user is shown the last second password entered,
for example password128,
and asked to enter a new second password
(pre-decided to be the last password entered with the last
digit incremented by one, for example password129),
so the second password changes all the time,
or something like this....

Danish wrote:
> On Feb 14, 8:59Âpm, Tony <nos...@example.com> wrote:
>
>> Not tested, but pretty sure it would work: Add a generated timestamp or
>> random string to the input name:
>> <input type="password" name="password_74234915">
>
> If I do end up taking this approach how would my program know what field
> name to expect?

Why does it need to know which field to expect? Just loop through *all*
the fields and find one which starts with "password_".

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 21 days, 16:46.]

Bottled Water
http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/

On Feb 18, 2:14pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> Danish wrote:
> > On Feb 14, 8:01 pm, WindsorFox <darkshado...@gmail.com> wrote:
> >> Danish wrote:
> >>> Hi,
> >>> I'm creating a web based database. The users of the database will
> >>> complete a login form with User Name and Password.
> >>> Many browsers offer the user the option of storing their login
> >>> details. For example: IE asks if you want to store the login details
> >>> when you click the submit button.
> >>> I need to know if there anything I can do when I create the login page
> >>> (which will be generated by a Perl program) which will either prevent
> >>> the browser from offering this option or prevent the user from
> >>> accepting it.
> >>> Any ideas welcome!
> >>> Nigel
> >> A site that did that to me I would never use again, but regardless,
> >> there are ways around it anyway.
>
> >> --
> >> "Yah know I hate it when forces gather in ma' fringe..." - Sheogorath
>
> >> "Daytime television sucked 20 years ago,
> >> and it still sucks today!" - Marc Bissonette- Hide quoted text -
>
> >> - Show quoted text -
>
> > Hi all,
>
> > Thanks for the various advice. I should have made clear that the site
> > I'm creating is for use only by a company's employees (so they don't
> > have the choice about whether to use it or not), that they may be
> > accessing the data from 'public' computers and that the data stored is
> > of a sensitive nature so security is of high importance.
>
> > I take the point about autocomplete making it easier for visitors to
> > use complex passwords. I already have in mind to expire passwords
> > after a set period and to enforce a mix of alphabetic and numeric
> > characters and a minimum length.
>
> > Thanks again,
>
> > Nigel
>
> But that won't stop browsers from storing passwords on those public
> computers. All it will do is keep the user from reusing the passwords.
> The password can still be on the computer - and readable by an
> administrator.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> ==================- Hide quoted text -
>
> - Show quoted text -

Hi Jerry,

You've got me worried now! Do you know how banks and such like get
around this security loop-hole?

I'm also wondering how the browser decides if the fields entered
represent a Login and Password pair.

I'm thinking of using the approach of randomising the two field names
as suggested by Tony, but would the issue you've referred to still
apply?

Nigel

Danish wrote:
> On Feb 18, 2:14 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Danish wrote:
>>> On Feb 14, 8:01 pm, WindsorFox <darkshado...@gmail.com> wrote:
>>>> Danish wrote:
>>>>> Hi,
>>>>> I'm creating a web based database. The users of the database will
>>>>> complete a login form with User Name and Password.
>>>>> Many browsers offer the user the option of storing their login
>>>>> details. For example: IE asks if you want to store the login details
>>>>> when you click the submit button.
>>>>> I need to know if there anything I can do when I create the login page
>>>>> (which will be generated by a Perl program) which will either prevent
>>>>> the browser from offering this option or prevent the user from
>>>>> accepting it.
>>>>> Any ideas welcome!
>>>>> Nigel
>>>> A site that did that to me I would never use again, but regardless,
>>>> there are ways around it anyway.
>>>> --
>>>> "Yah know I hate it when forces gather in ma' fringe..." - Sheogorath
>>>> "Daytime television sucked 20 years ago,
>>>> and it still sucks today!" - Marc Bissonette- Hide quoted text -
>>>> - Show quoted text -
>>> Hi all,
>>> Thanks for the various advice. I should have made clear that the site
>>> I'm creating is for use only by a company's employees (so they don't
>>> have the choice about whether to use it or not), that they may be
>>> accessing the data from 'public' computers and that the data stored is
>>> of a sensitive nature so security is of high importance.
>>> I take the point about autocomplete making it easier for visitors to
>>> use complex passwords. I already have in mind to expire passwords
>>> after a set period and to enforce a mix of alphabetic and numeric
>>> characters and a minimum length.
>>> Thanks again,
>>> Nigel
>> But that won't stop browsers from storing passwords on those public
>> computers. All it will do is keep the user from reusing the passwords.
>> The password can still be on the computer - and readable by an
>> administrator.
>>
>> --
>> ==================
>> Remove the "x" from my email address
>> Jerry Stuckle
>> JDS Computer Training Corp.
>> jstuck...@attglobal.net
>> ==================- Hide quoted text -
>>
>> - Show quoted text -
>
> Hi Jerry,
>
> You've got me worried now! Do you know how banks and such like get
> around this security loop-hole?
>
> I'm also wondering how the browser decides if the fields entered
> represent a Login and Password pair.
>
> I'm thinking of using the approach of randomising the two field names
> as suggested by Tony, but would the issue you've referred to still
> apply?
>
> Nigel
>
>

Yes, you can randomize them - but the issue is still there. You can't
control browser behavior.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Danish wrote:
> Hi Jerry,
>
> You've got me worried now! Do you know how banks and such like get
> around this security loop-hole?

They don't. ALL of my accounts have the login info stored on my computer.

> I'm also wondering how the browser decides if the fields entered
> represent a Login and Password pair.
>
> I'm thinking of using the approach of randomising the two field names
> as suggested by Tony, but would the issue you've referred to still
> apply?

Not viewable easily, but as he said, still available to an admin. And
still annoying to your users.

On Feb 20, 7:53pm, Tony <nos...@example.com> wrote:
> Danish wrote:
> > Hi Jerry,
>
> > You've got me worried now! Do you know how banks and such like get
> > around this security loop-hole?
>
> They don't. ALL of my accounts have the login info stored on my computer.
>
> > I'm also wondering how the browser decides if the fields entered
> > represent a Login and Password pair.
>
> > I'm thinking of using the approach of randomising the two field names
> > as suggested by Tony, but would the issue you've referred to still
> > apply?
>
> Not viewable easily, but as he said, still available to an admin. And
> still annoying to your users.

So to recap - I can't stop the browser storing a Login/Password pair
(although I'm still unclear how the browser determines that is has
such a pair) and although I can use randomised field names so that
storing the Login/Password pair won't the bone fide user to
Login, that won't stop a potential hacker finding the information they
need. What a pain!

My bank asks me to enter two specified letters from my password, so my
whole password is never entered, but I think that is getting a bit
extreme for a simple database.

Perhaps a possible solution is to use a to store the User Name.
Then the login screen can simply accept their password and password
fields on their own don't autocomplete (I think?) Add a link to change
user and we're sorted...unless you know different. I know the password
is still stored somewhere on the computer, but someone would have to
dig to find it...

In any case this is a decision that may well end up being made in
favour of the "appearance" of security in preference to ease of use,
but I'll try and make the arguement!

Thanks for all your comments to date...

Nigel

Danish wrote:
>
> So to recap - I can't stop the browser storing a Login/Password pair
> (although I'm still unclear how the browser determines that is has
> such a pair) and although I can use randomised field names so that
> storing the Login/Password pair won't the bone fide user to
> Login, that won't stop a potential hacker finding the information they
> need. What a pain!
>
> My bank asks me to enter two specified letters from my password, so my
> whole password is never entered, but I think that is getting a bit
> extreme for a simple database.

http://www.schneier.com/blog/archive...curity_vu.html

The thing is, no matter what you do, the user can find a way to store
that info.

> Perhaps a possible solution is to use a to store the User Name.

I think that's even worse from a security standpoint.

> Then the login screen can simply accept their password and password
> fields on their own don't autocomplete (I think?) Add a link to change
> user and we're sorted...unless you know different. I know the password
> is still stored somewhere on the computer, but someone would have to
> dig to find it...

Not at all. Finding the contents of is even easier than finding
the content of stored username/password pairs.

> In any case this is a decision that may well end up being made in
> favour of the "appearance" of security in preference to ease of use,
> but I'll try and make the arguement!

Again, why would you want to annoy your users? I truly can't understand
why companies do this. ANYTHING that makes it harder for your user is a
reason for them to go elsewhere. And as easy as that is on the internet,
they will.

And if they get an inkling that your "appearance" of security is bogus,
they'll not only dump you, but there may be other consequences as well.
I wouldn't want to begin thinking about what they may be.

Here - for when you make your argument (a shameless plug for a rant of
my own):
http://www.patternsofchaos.net/blog/?p=10