Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.misc > #3484 > unrolled thread

The "Cobra Effect" that is disabling paste on password fields

Back to article view | Back to comp.misc

Contents

  The "Cobra Effect" that is disabling paste on password fields Rich <rich@example.invalid> - 2014-06-02 11:53 +0000
    Re: The "Cobra Effect" that is disabling paste on password fields "tdk" <forum.tdk@squte.com> - 2014-06-02 08:27 -0500
      Re: The "Cobra Effect" that is disabling paste on password fields Rich <rich@example.invalid> - 2014-06-02 15:32 +0000
        Re: The "Cobra Effect" that is disabling paste on password fields Jerry Peters <jerry@example.invalid> - 2014-06-02 18:31 +0000
        Re: The "Cobra Effect" that is disabling paste on password fields Sylvia Else <sylvia@not.at.this.address> - 2014-06-03 13:15 +1000
          Re: The "Cobra Effect" that is disabling paste on password fields Rich <rich@example.invalid> - 2014-06-03 10:26 +0000
            Re: The "Cobra Effect" that is disabling paste on password fields Sylvia Else <sylvia@not.at.this.address> - 2014-06-03 21:03 +1000
            Re: The "Cobra Effect" that is disabling paste on password fields Jerry Peters <jerry@example.invalid> - 2014-06-03 20:20 +0000
              Re: The "Cobra Effect" that is disabling paste on password fields Rich <rich@example.invalid> - 2014-06-04 01:45 +0000
                Re: The "Cobra Effect" that is disabling paste on password fields Sylvia Else <sylvia@not.at.this.address> - 2014-06-04 17:16 +1000
                  Re: The "Cobra Effect" that is disabling paste on password fields Rich <rich@example.invalid> - 2014-06-04 09:37 +0000
                Re: The "Cobra Effect" that is disabling paste on password fields Jerry Peters <jerry@example.invalid> - 2014-06-04 20:15 +0000
          Re: The "Cobra Effect" that is disabling paste on password fields Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-06-04 11:06 +0100
        Re: The "Cobra Effect" that is disabling paste on password fields Huge <Huge@nowhere.much.invalid> - 2014-06-05 18:41 +0000
      Re: The "Cobra Effect" that is disabling paste on password fields Paul Sture <nospam@sture.ch> - 2014-06-04 07:19 +0200
        Re: The "Cobra Effect" that is disabling paste on password fields Rich <rich@example.invalid> - 2014-06-04 10:00 +0000
          Re: The "Cobra Effect" that is disabling paste on password fields David Harmon <source@netcom.com> - 2014-06-04 07:54 -0700
          Re: The "Cobra Effect" that is disabling paste on password fields Mike Spencer <mds@bogus.nodomain.nowhere> - 2014-06-04 23:49 -0300
            Re: The "Cobra Effect" that is disabling paste on password fields "tdk" <forum.tdk@squte.com> - 2014-06-05 05:55 -0500
    Re: The "Cobra Effect" that is disabling paste on password fields Gordon Henderson <gordon+usenet@drogon.net> - 2014-06-03 07:42 +0000
      Re: The "Cobra Effect" that is disabling paste on password fields polygonum <rmoudndgers@vrod.co.uk> - 2014-06-03 18:39 +0100
      Re: The "Cobra Effect" that is disabling paste on password fields scott@alfter.diespammersdie.us (Scott Alfter) - 2014-06-04 16:00 +0000

Page 1 of 2  [1] 2  Next page →

#3484 — The "Cobra Effect" that is disabling paste on password fields

http://www.troyhunt.com/2014/05/the-cobra-effect-that-is-disabling.html

"Back in the day when the British had a penchant for conquering the
world, they ran into a little problem on the subcontinent; cobras.
Turns out there were a hell of a lot of the buggers wandering around
India and it also turned out that they were rather venomous which
didn't sit well with the colonials. Ingenious as the British were, they
decided to offer the citizens a bounty - you hand in dead cobras that
would otherwise have bitten some poor imperialist and you get some
cash. Problem solved."

"Unfortunately, the enterprising locals saw things differently and
interpreted the "cash for cobras" scheme as a damn good reason to start
breeding serpents and raking in the dollars. Having now seen the flaw
in their original logical, the poms quickly scrapped the scheme meaning
no more snake bounty. Naturally the only thing for the locals to do
with their now worthless cobras was to set them free so that they may
seek out a nice cosy British settlement somewhere."

"This became known as the Cobra Effect or in other words, a solution to
a problem that actually makes the whole thing a lot worse. Here\u2019s
a modern day implementation of the Cobra Effect as it relates to the
ability to paste your password into a login field:"

  "@passy We'd lose our security certificate if we allowed pasting. It
  could leave us open to a "brute force" attack. Thanks ^Steve"

...

[toc] | [next] | [standalone]

#3485

>We'd lose our security certificate if we allowed pasting. It could leave us  
>open to a "brute force" attack.
It is of course ridiculous to think that brute forcing is done by  
copy-pasting (with JavaScript enabled!) but a legitimate reason to force  
users to retype their password might be so a single typo doesn't become part  
of it. They are much less likely to mistype exactly the same way twice. This  
might be why some sites allow pasting on login but not when entering a new  
password.

I've never actually experienced this; I usually have JavaScript off and use  
select + middle-click (on Linux) instead of ctrl-V

-- 
regards
~tdk
View this thread at http://squte.com/node/6242#comment-28221

[toc] | [prev] | [next] | [standalone]

#3487

tdk <forum.tdk@squte.com> wrote:
> >We'd lose our security certificate if we allowed pasting. It could leave us  
> >open to a "brute force" attack.

> It is of course ridiculous to think that brute forcing is done by  
> copy-pasting (with JavaScript enabled!)

But it looks like some "web-security best practices seminar" somewhere
has begun to "teach" that allowing pasting is a security issue.  The
question is, how do we stop it before it grows too far?

> but a legitimate reason to force users to retype their password might
> be so a single typo doesn't become part of it. They are much less
> likely to mistype exactly the same way twice. This might be why some
> sites allow pasting on login but not when entering a new password.

Not unreasonable, but if the password reset subsystem is sufficiently
easy to use, also not really an issue to be too concerned about
overall.

> I've never actually experienced this; I usually have JavaScript off
> and use select + middle-click (on Linux) instead of ctrl-V

If you read down into the article, the blocking of paste operations is
driven by javascript.  Without javascript turned on, pasting still
works properly.

[toc] | [prev] | [next] | [standalone]

#3494

Rich <rich@example.invalid> wrote:
> tdk <forum.tdk@squte.com> wrote:
>> >We'd lose our security certificate if we allowed pasting. It could leave us  
>> >open to a "brute force" attack.
> 
>> It is of course ridiculous to think that brute forcing is done by  
>> copy-pasting (with JavaScript enabled!)
> 
> But it looks like some "web-security best practices seminar" somewhere
> has begun to "teach" that allowing pasting is a security issue.  The
> question is, how do we stop it before it grows too far?
> 
>> but a legitimate reason to force users to retype their password might
>> be so a single typo doesn't become part of it. They are much less
>> likely to mistype exactly the same way twice. This might be why some
>> sites allow pasting on login but not when entering a new password.
> 
> Not unreasonable, but if the password reset subsystem is sufficiently
> easy to use, also not really an issue to be too concerned about
> overall.
> 
>> I've never actually experienced this; I usually have JavaScript off
>> and use select + middle-click (on Linux) instead of ctrl-V
> 
> If you read down into the article, the blocking of paste operations is
> driven by javascript.  Without javascript turned on, pasting still
> works properly.

The stupidity is amazing, then again, I've had to deal with auditors
in the past, let's just say many of them are not that bright.

It's a PITA when you use a password manager that generates *strong* &
long passwords. Typing say 20 random characters blindly even once is a
challenge. So what they're in effect doing with their idiotic policy
is encouraging people to use short and/or weak passwords.

[toc] | [prev] | [next] | [standalone]

#3497

On 3/06/2014 1:32 AM, Rich wrote:
> tdk <forum.tdk@squte.com> wrote:
>>> We'd lose our security certificate if we allowed pasting. It could leave us
>>> open to a "brute force" attack.
>
>> It is of course ridiculous to think that brute forcing is done by
>> copy-pasting (with JavaScript enabled!)
>
> But it looks like some "web-security best practices seminar" somewhere
> has begun to "teach" that allowing pasting is a security issue.  The
> question is, how do we stop it before it grows too far?

We could try to find out where this nonsense is coming from.

Or we could just program around it. I doubt it would be that difficult 
to allow a program to insert characters into the keyboard input stream 
so that another program sees them as if they're actually been typed.

Of course, that may have security implications too....

Sylvia.

[toc] | [prev] | [next] | [standalone]

#3499

Sylvia Else <sylvia@not.at.this.address> wrote:
> On 3/06/2014 1:32 AM, Rich wrote:
> > tdk <forum.tdk@squte.com> wrote:
> >>> We'd lose our security certificate if we allowed pasting. It could leave us
> >>> open to a "brute force" attack.
> >
> >> It is of course ridiculous to think that brute forcing is done by
> >> copy-pasting (with JavaScript enabled!)
> >
> > But it looks like some "web-security best practices seminar" somewhere
> > has begun to "teach" that allowing pasting is a security issue.  The
> > question is, how do we stop it before it grows too far?

> We could try to find out where this nonsense is coming from.

> Or we could just program around it. I doubt it would be that difficult 
> to allow a program to insert characters into the keyboard input stream 
> so that another program sees them as if they're actually been typed.

Another option might be a bookmarklet that iterated the document.forms
DOM object, looking for inputs with an onpaste event attached, and then
simply removing the onpaste event(s).

That seems to be how the fools are blocking pasting, setting the
onpaste event of the DOM input element that is the password box to
return false.

[toc] | [prev] | [next] | [standalone]

#3500

On 3/06/2014 8:26 PM, Rich wrote:
> Sylvia Else <sylvia@not.at.this.address> wrote:
>> On 3/06/2014 1:32 AM, Rich wrote:
>>> tdk <forum.tdk@squte.com> wrote:
>>>>> We'd lose our security certificate if we allowed pasting. It could leave us
>>>>> open to a "brute force" attack.
>>>
>>>> It is of course ridiculous to think that brute forcing is done by
>>>> copy-pasting (with JavaScript enabled!)
>>>
>>> But it looks like some "web-security best practices seminar" somewhere
>>> has begun to "teach" that allowing pasting is a security issue.  The
>>> question is, how do we stop it before it grows too far?
>
>> We could try to find out where this nonsense is coming from.
>
>> Or we could just program around it. I doubt it would be that difficult
>> to allow a program to insert characters into the keyboard input stream
>> so that another program sees them as if they're actually been typed.
>
> Another option might be a bookmarklet that iterated the document.forms
> DOM object, looking for inputs with an onpaste event attached, and then
> simply removing the onpaste event(s).
>
> That seems to be how the fools are blocking pasting, setting the
> onpaste event of the DOM input element that is the password box to
> return false.
>

Even easier then.

Sylvia.

[toc] | [prev] | [next] | [standalone]

#3504

Rich <rich@example.invalid> wrote:
> Sylvia Else <sylvia@not.at.this.address> wrote:
>> On 3/06/2014 1:32 AM, Rich wrote:
>> > tdk <forum.tdk@squte.com> wrote:
>> >>> We'd lose our security certificate if we allowed pasting. It could leave us
>> >>> open to a "brute force" attack.
>> >
>> >> It is of course ridiculous to think that brute forcing is done by
>> >> copy-pasting (with JavaScript enabled!)
>> >
>> > But it looks like some "web-security best practices seminar" somewhere
>> > has begun to "teach" that allowing pasting is a security issue.  The
>> > question is, how do we stop it before it grows too far?
> 
>> We could try to find out where this nonsense is coming from.
> 
>> Or we could just program around it. I doubt it would be that difficult 
>> to allow a program to insert characters into the keyboard input stream 
>> so that another program sees them as if they're actually been typed.
> 
> Another option might be a bookmarklet that iterated the document.forms
> DOM object, looking for inputs with an onpaste event attached, and then
> simply removing the onpaste event(s).
> 
> That seems to be how the fools are blocking pasting, setting the
> onpaste event of the DOM input element that is the password box to
> return false.
> 

I have a FF bookmarklet that purports to do just that. Haven't tried
it yet:
javascript:(function(){var%20inputs=document.getElementsByTagName('input');for(var%20i=0;i<inputs.length;i++){if(inputs[i].getAttribute('type').toLowerCase()==='password'){inputs[i].setAttribute('onpaste','');}}})();

If you create abookmark & paste that string into it, it should work.

I also have some other interesting bookmarklets that I got from a FF
site, the zap colors is useful for some of the bizarre, barely
readable color combos some artistic types seem to prefer.

[toc] | [prev] | [next] | [standalone]

#3506

Jerry Peters <jerry@example.invalid> wrote:
> Rich <rich@example.invalid> wrote:
> > Sylvia Else <sylvia@not.at.this.address> wrote:
> >> On 3/06/2014 1:32 AM, Rich wrote:
> >> > tdk <forum.tdk@squte.com> wrote:
> >> >>> We'd lose our security certificate if we allowed pasting. It could leave us
> >> >>> open to a "brute force" attack.
> >> >
> >> >> It is of course ridiculous to think that brute forcing is done by
> >> >> copy-pasting (with JavaScript enabled!)
> >> >
> >> > But it looks like some "web-security best practices seminar" somewhere
> >> > has begun to "teach" that allowing pasting is a security issue.  The
> >> > question is, how do we stop it before it grows too far?
> > 
> >> We could try to find out where this nonsense is coming from.
> > 
> >> Or we could just program around it. I doubt it would be that difficult 
> >> to allow a program to insert characters into the keyboard input stream 
> >> so that another program sees them as if they're actually been typed.
> > 
> > Another option might be a bookmarklet that iterated the document.forms
> > DOM object, looking for inputs with an onpaste event attached, and then
> > simply removing the onpaste event(s).
> > 
> > That seems to be how the fools are blocking pasting, setting the
> > onpaste event of the DOM input element that is the password box to
> > return false.
> > 

> I have a FF bookmarklet that purports to do just that. Haven't tried
> it yet:

It does indeed "unset" any set onpaste event.  Reformatting it
slightly, and adding some comments:

javascript:( function(){

  /* get all <input> tags */
  var inputs=document.getElementsByTagName('input');

  /* iterate over each <input> tag */
  for (var i=0; i<inputs.length; i++) { 

    /* check to see if the <input> is type="password" */
    if (inputs[i].getAttribute('type').toLowerCase()==='password') {

      /* if yes, set onpaste='' (nothing) */
      inputs[i].setAttribute('onpaste','');
    }
  }
 })();

[toc] | [prev] | [next] | [standalone]

#3508

On 4/06/2014 11:45 AM, Rich wrote:
> Jerry Peters <jerry@example.invalid> wrote:
>> Rich <rich@example.invalid> wrote:
>>> Sylvia Else <sylvia@not.at.this.address> wrote:
>>>> On 3/06/2014 1:32 AM, Rich wrote:
>>>>> tdk <forum.tdk@squte.com> wrote:
>>>>>>> We'd lose our security certificate if we allowed pasting. It could leave us
>>>>>>> open to a "brute force" attack.
>>>>>
>>>>>> It is of course ridiculous to think that brute forcing is done by
>>>>>> copy-pasting (with JavaScript enabled!)
>>>>>
>>>>> But it looks like some "web-security best practices seminar" somewhere
>>>>> has begun to "teach" that allowing pasting is a security issue.  The
>>>>> question is, how do we stop it before it grows too far?
>>>
>>>> We could try to find out where this nonsense is coming from.
>>>
>>>> Or we could just program around it. I doubt it would be that difficult
>>>> to allow a program to insert characters into the keyboard input stream
>>>> so that another program sees them as if they're actually been typed.
>>>
>>> Another option might be a bookmarklet that iterated the document.forms
>>> DOM object, looking for inputs with an onpaste event attached, and then
>>> simply removing the onpaste event(s).
>>>
>>> That seems to be how the fools are blocking pasting, setting the
>>> onpaste event of the DOM input element that is the password box to
>>> return false.
>>>
>
>> I have a FF bookmarklet that purports to do just that. Haven't tried
>> it yet:
>
> It does indeed "unset" any set onpaste event.  Reformatting it
> slightly, and adding some comments:
>
> javascript:( function(){
>
>    /* get all <input> tags */
>    var inputs=document.getElementsByTagName('input');
>
>    /* iterate over each <input> tag */
>    for (var i=0; i<inputs.length; i++) {
>
>      /* check to see if the <input> is type="password" */
>      if (inputs[i].getAttribute('type').toLowerCase()==='password') {
>
>        /* if yes, set onpaste='' (nothing) */
>        inputs[i].setAttribute('onpaste','');
>      }
>    }
>   })();
>

It's specifically targeted at password fields. I'm trying to think 
whether there's any valid reason (from a user's perspective) for ever 
prohibiting paste into fields, whether password or not.

Sylvia.

[toc] | [prev] | [next] | [standalone]

#3510

Sylvia Else <sylvia@not.at.this.address> wrote:
> On 4/06/2014 11:45 AM, Rich wrote:
> > Jerry Peters <jerry@example.invalid> wrote:
> >> Rich <rich@example.invalid> wrote:
> >>> Sylvia Else <sylvia@not.at.this.address> wrote:
> >>>> On 3/06/2014 1:32 AM, Rich wrote:
> >>>>> tdk <forum.tdk@squte.com> wrote:
> >>>>>>> We'd lose our security certificate if we allowed pasting. It could leave us
> >>>>>>> open to a "brute force" attack.
> >>>>>
> >>>>>> It is of course ridiculous to think that brute forcing is done by
> >>>>>> copy-pasting (with JavaScript enabled!)
> >>>>>
> >>>>> But it looks like some "web-security best practices seminar" somewhere
> >>>>> has begun to "teach" that allowing pasting is a security issue.  The
> >>>>> question is, how do we stop it before it grows too far?
> >>>
> >>>> We could try to find out where this nonsense is coming from.
> >>>
> >>>> Or we could just program around it. I doubt it would be that difficult
> >>>> to allow a program to insert characters into the keyboard input stream
> >>>> so that another program sees them as if they're actually been typed.
> >>>
> >>> Another option might be a bookmarklet that iterated the document.forms
> >>> DOM object, looking for inputs with an onpaste event attached, and then
> >>> simply removing the onpaste event(s).
> >>>
> >>> That seems to be how the fools are blocking pasting, setting the
> >>> onpaste event of the DOM input element that is the password box to
> >>> return false.
> >>>
> >
> >> I have a FF bookmarklet that purports to do just that. Haven't tried
> >> it yet:
> >
> > It does indeed "unset" any set onpaste event.  Reformatting it
> > slightly, and adding some comments:
> >
> > javascript:( function(){
> >
> >    /* get all <input> tags */
> >    var inputs=document.getElementsByTagName('input');
> >
> >    /* iterate over each <input> tag */
> >    for (var i=0; i<inputs.length; i++) {
> >
> >      /* check to see if the <input> is type="password" */
> >      if (inputs[i].getAttribute('type').toLowerCase()==='password') {
> >
> >        /* if yes, set onpaste='' (nothing) */
> >        inputs[i].setAttribute('onpaste','');
> >      }
> >    }
> >   })();
> >

> It's specifically targeted at password fields.

That is true - I did not attempt to extend it in any way yet.

> I'm trying to think whether there's any valid reason (from a user's
> perspective) for ever prohibiting paste into fields, whether password
> or not.

For prohibiting paste, no, I don't see any valid reason.  For catching
a paste event to a field so that the code can do the right thing
(whatever that might be) for a web-app then there might be a reason.

If you wanted to undo all paste overrides, just remove the if clause
that checks for 'type' == 'password' and it will clear the onpaste=''
attribute of every single <input> field.  That would leave
<textareas> unchanged, so the code might need a bit of expansion to
work on both <input> and <textarea> (that is assuming that someone
would try to block paste into a text area).  I hope no one would do
that, but sadly, I suspect some fool does somewhere.

[toc] | [prev] | [next] | [standalone]

#3519

Rich <rich@example.invalid> wrote:
> Jerry Peters <jerry@example.invalid> wrote:
>> Rich <rich@example.invalid> wrote:
>> > Sylvia Else <sylvia@not.at.this.address> wrote:
>> >> On 3/06/2014 1:32 AM, Rich wrote:
>> >> > tdk <forum.tdk@squte.com> wrote:
>> >> >>> We'd lose our security certificate if we allowed pasting. It could leave us
>> >> >>> open to a "brute force" attack.
>> >> >
>> >> >> It is of course ridiculous to think that brute forcing is done by
>> >> >> copy-pasting (with JavaScript enabled!)
>> >> >
>> >> > But it looks like some "web-security best practices seminar" somewhere
>> >> > has begun to "teach" that allowing pasting is a security issue.  The
>> >> > question is, how do we stop it before it grows too far?
>> > 
>> >> We could try to find out where this nonsense is coming from.
>> > 
>> >> Or we could just program around it. I doubt it would be that difficult 
>> >> to allow a program to insert characters into the keyboard input stream 
>> >> so that another program sees them as if they're actually been typed.
>> > 
>> > Another option might be a bookmarklet that iterated the document.forms
>> > DOM object, looking for inputs with an onpaste event attached, and then
>> > simply removing the onpaste event(s).
>> > 
>> > That seems to be how the fools are blocking pasting, setting the
>> > onpaste event of the DOM input element that is the password box to
>> > return false.
>> > 
> 
>> I have a FF bookmarklet that purports to do just that. Haven't tried
>> it yet:
> 
> It does indeed "unset" any set onpaste event.  Reformatting it
> slightly, and adding some comments:
> 
> javascript:( function(){
> 
>  /* get all <input> tags */
>  var inputs=document.getElementsByTagName('input');
> 
>  /* iterate over each <input> tag */
>  for (var i=0; i<inputs.length; i++) { 
> 
>    /* check to see if the <input> is type="password" */
>    if (inputs[i].getAttribute('type').toLowerCase()==='password') {
> 
>      /* if yes, set onpaste='' (nothing) */
>      inputs[i].setAttribute('onpaste','');
>    }
>  }
> })();
> 

Thanks, it looked like it would work, I just haven't had any occasion to
use it yet

[toc] | [prev] | [next] | [standalone]

#3514

Sylvia Else <sylvia@not.at.this.address> writes:

> On 3/06/2014 1:32 AM, Rich wrote:
>> tdk <forum.tdk@squte.com> wrote:
>>>> We'd lose our security certificate if we allowed pasting. It could leave us
>>>> open to a "brute force" attack.
>>
>>> It is of course ridiculous to think that brute forcing is done by
>>> copy-pasting (with JavaScript enabled!)
>>
>> But it looks like some "web-security best practices seminar" somewhere
>> has begun to "teach" that allowing pasting is a security issue.  The
>> question is, how do we stop it before it grows too far?
>
> We could try to find out where this nonsense is coming from.
>
> Or we could just program around it. I doubt it would be that difficult
> to allow a program to insert characters into the keyboard input stream
> so that another program sees them as if they're actually been typed.

I have a home-grown password management program that does exactly this.
A password unlocks the system and the keystrokes (including tabs and
newlines) are injecting into the input stream.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#3524

On 2014-06-02, Rich <rich@example.invalid> wrote:
> tdk <forum.tdk@squte.com> wrote:
>> >We'd lose our security certificate if we allowed pasting. It could leave us  
>> >open to a "brute force" attack.
>
>> It is of course ridiculous to think that brute forcing is done by  
>> copy-pasting (with JavaScript enabled!)
>
> But it looks like some "web-security best practices seminar" somewhere
> has begun to "teach" that allowing pasting is a security issue.  The
> question is, how do we stop it before it grows too far?

You can't.

Far too many stupidities are already engrained in the password nonsense. This
is just another.

-- 
Today is Sweetmorn, the 10th day of Confusion in the YOLD 3180
"I do not believe in revealed religion — I will have nothing to do with your
immortality; we are miserable enough in this life, without speculating on
another." Lord Byron, 1778-1824, letter to Rev. Francis Hodgson, 1811

[toc] | [prev] | [next] | [standalone]

#3507

On 2014-06-02, tdk <forum.tdk@squte.com> wrote:
>>We'd lose our security certificate if we allowed pasting. It could leave us  
>>open to a "brute force" attack.
>
> It is of course ridiculous to think that brute forcing is done by  
> copy-pasting (with JavaScript enabled!) but a legitimate reason to force  
> users to retype their password might be so a single typo doesn't become part  
> of it. They are much less likely to mistype exactly the same way twice. This  
> might be why some sites allow pasting on login but not when entering a new  
> password.

The problem with that theory is that I do find myself repeating a typo
in password creation and modification dialogues.

A couple of points:

1) Have folks forgotten *why* check digits on account numbers became
   standard practice?
2) Many folks use spell checkers even though they are perfectly capable
   of spelling correctly; they use them to catch typos.

I am sure there was a fair bit of research conducted into 1) back in the
early days of computing.  It's probably worthwhile digging that out.

> I've never actually experienced this; I usually have JavaScript off and use  
> select + middle-click (on Linux) instead of ctrl-V

Some sites won't even let you get as far as the password prompt without
JavaScript enabled.

-- 
Paul Sture

The final step of #heartbleed recovery is to call your mother, and advise
her to change her maiden name                                  -- @gojomo

[toc] | [prev] | [next] | [standalone]

#3511

Paul Sture <nospam@sture.ch> wrote:
> On 2014-06-02, tdk <forum.tdk@squte.com> wrote:
> >>We'd lose our security certificate if we allowed pasting. It could
> >>leave us open to a "brute force" attack.
> >
> > It is of course ridiculous to think that brute forcing is done by
> > copy-pasting (with JavaScript enabled!) but a legitimate reason to
> > force users to retype their password might be so a single typo
> > doesn't become part of it. They are much less likely to mistype
> > exactly the same way twice. This might be why some sites allow
> > pasting on login but not when entering a new password.

> The problem with that theory is that I do find myself repeating a
> typo in password creation and modification dialogues.

An issue that when it occurs can be cured by making the password reset
feature have less friction.

The problem with the no-paste mindset is that it attempts to solve one
problem by creating a worse unintended consequence.  I use a password
manager, so 

1) my password will look something like this: 1i^G2U8~5qQDhvVYcHYF
   (that's an actual random output from the manager, just not a
   password I'm using anywhere);

2) because I'm using a password manager, the one-two retype password
   boxes always receive identical content, because the manager is
   pasting in the password instead of me typing it.

So I don't even need the one-two boxes, because the first entry box
will get exactly what was generated by the manager.  So breaking paste
does no good for me, because the computer does not make typo's that
would need catching.

But, breaking paste into the password field means I can't use the
password manager for the site (I'm excluding the fact that I, personally,
know how to use the web. dev. tools to fix a broken site, because some
subset of individuals using password managers will not know how to do
so).  Also, I am not going to be able to remember 1i^G2U8~5qQDhvVYcHYF
to manually type it.  So my options become:

1) try to manually type 1i^G2U8~5qQDhvVYcHYF from the manager into the
   password boxes;

2) use a weak password that I can type and can remember;

3) don't use the site.

Myself, #3 is what the "break paste" mindset will get for the site. 
Sadly, for some subset of folks however, they will go with #2, and so
the effect is a reduction of security for that user, and an
encouragement to not use good high-security passwords (and a manager),
further reducing their security profile.

The result of this is by far worse than a subset of users having to
sometimes reset their passwords when they are actually typing, and made
an actual typo.

> A couple of points:

> 1) Have folks forgotten *why* check digits on account numbers became
>    standard practice?

No, but blocking paste is not the same as adding check digits to an
account number.  Both relate to prevention of accidental typos yes, but
the net usability effect is not at all the same.

> 2) Many folks use spell checkers even though they are perfectly capable
>    of spelling correctly; they use them to catch typos.

True, but again, not the same usability effect.  A system with
spellcheck that prevented you from copy/pasting anything would be
similar in usability.

> > I've never actually experienced this; I usually have JavaScript off and use  
> > select + middle-click (on Linux) instead of ctrl-V

> Some sites won't even let you get as far as the password prompt without
> JavaScript enabled.

Sites that fail to operate with Javascript turned off I simply do not
bother with in most instances.

Sites that require javascript to get to the login prompt also do not
actually want my business, so I go elsewhere.

Unfortunately there are not enough users who feel the same to cause
those sites to see the errors of their ways in their usage logs.

[toc] | [prev] | [next] | [standalone]

#3516

On Wed, 4 Jun 2014 10:00:36 +0000 (UTC) in comp.misc, Rich
<rich@example.invalid> wrote,
>Paul Sture <nospam@sture.ch> wrote:
>> 2) Many folks use spell checkers even though they are perfectly capable
>>    of spelling correctly; they use them to catch typos.
>
>True, but again, not the same usability effect.  A system with
>spellcheck that prevented you from copy/pasting anything would be
>similar in usability.

I'm thinking it wouldn't prevent you from pasting, it would just
silently correct spelling errors in the masked password field.

[toc] | [prev] | [next] | [standalone]

#3520

Rich <rich@example.invalid> writes:

> Paul Sture <nospam@sture.ch> wrote:
>
>> Some sites won't even let you get as far as the password prompt without
>> JavaScript enabled.
> 
> Sites that fail to operate with Javascript turned off I simply do not
> bother with in most instances.
> 
> Sites that require javascript to get to the login prompt also do not
> actually want my business, so I go elsewhere.
> 
> Unfortunately there are not enough users who feel the same to cause
> those sites to see the errors of their ways in their usage logs.

Twenty-five years ago, Nicholas Negroponte, at the MIT Media Lab, was
waxing enthusiastic about a near future when we'd all have "software
agents" out there in cyberspace, doing useful things for us.

My response was, "Sounds like the work of Nick Haflinger in Shockwave
Rider to me."   Who wants other people's "agents" running on their
machines?  

Now we have a bimodal distribution of Negroponte's future.  If you're
a well-funded institution, you can put pages and pages of javascript
onto any machine whose owner likes your eye candy or your whiz-bang
$COOL_FEATURES.  

The rest of us?  I'd like, say, to have some statistics about usage of
an OTC drug and long-term hepatic function -- a very commendable
investigation -- so I'll just write an "agent" that will find its way
into 5000 physicians' computers and report that back to me.  'Scuse me
but I have to see who's trying to break down the door, eh?

I'm with Rich. It's a rare case with a compelling need for info in
which I'll visit a site that compels js for access.

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#3521

Mike Spencer wrote:

>so I'll just write an "agent" that will find its way into 5000 physicians'  
>computers and report that back to me.
There's a difference between using resources on a remote pc and using the  
data that happens to be stored on it.

Hackers are already using distributed software agents to mine for bitcoins,  
botnets are running software agents - and where blackhats go now, the  
whitehats will follow.

On a pc with proper security and privileges there's no reason not to allow  
arbitrary code to run without risking your data or uptime*. Maybe some day if  
you have a server you can rent out its resources (cpu, disc space) in slack  
times in return for using other's resources at peak times. People with  
thinnish clients will be able to rent from this same pool - even running  
X-clients in it if needed. Some probes in this direction are screensavers  
like Models@Home [1]. Buddybackup [2] already does this with disk space -  
only for backup ATM, but its easy to see how it could be a 'distributed disc  
drive'.

Replacing the current 'clouds' with benevolent botnets that would be immune  
from court orders, natural disasters, corporate lock-in etc would be a big  
win.

* on Windows this is called a 'virus' which tells you something about Windows  
security.


[1] http://www.ncbi.nlm.nih.gov/pubmed/11847079
[2] http://www.buddybackup.com/
-- 
regards
~tdk
View this thread at http://squte.com/node/6242#comment-28483

[toc] | [prev] | [next] | [standalone]

#3498

In article <lmhokh$2kb$1@dont-email.me>, Rich  <rich@example.invalid> wrote:
>http://www.troyhunt.com/2014/05/the-cobra-effect-that-is-disabling.html
>...
>"This became known as the Cobra Effect or in other words, a solution to
>a problem that actually makes the whole thing a lot worse. Here\u2019s
>a modern day implementation of the Cobra Effect as it relates to the
>ability to paste your password into a login field:"
>
>  "@passy We'd lose our security certificate if we allowed pasting. It
>  could leave us open to a "brute force" attack. Thanks ^Steve"

With the now (?) obligatory references to XKCD:

Not password, but: http://xkcd.com/970/

and

  http://xkcd.com/936/

I complained to O2 once about them asking for my email address twice,
refering the to 970, saying I'd just copy & paste, so they changed
their webshite to block copy & paste. I'm not an O2 customer any more.

Gordon

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.misc

csiph-web