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


Groups > comp.misc > #3508

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

From Sylvia Else <sylvia@not.at.this.address>
Newsgroups comp.misc
Subject Re: The "Cobra Effect" that is disabling paste on password fields
Date 2014-06-04 17:16 +1000
Message-ID <bv7veqF7erU1@mid.individual.net> (permalink)
References (2 earlier) <lmi5du$15e$1@dont-email.me> <bv4su5Fb08cU1@mid.individual.net> <lmk7tj$o51$1@dont-email.me> <lmlali$aic$1@dont-email.me> <lmltoi$cj7$1@dont-email.me>

Show all headers | View raw


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.

Back to comp.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web