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

Groups > comp.lang.python > #101643 > unrolled thread

Re: [Python-ideas] Password masking for getpass.getpass

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Python-ideas] Password masking for getpass.getpass Chris Angelico <rosuav@gmail.com> - 2016-01-14 11:27 +1100
    Re: [Python-ideas] Password masking for getpass.getpass Steven D'Aprano <steve@pearwood.info> - 2016-01-14 11:47 +1100
      Re: [Python-ideas] Password masking for getpass.getpass Michael Torrie <torriem@gmail.com> - 2016-01-13 17:59 -0700
      Re: [Python-ideas] Password masking for getpass.getpass Marko Rauhamaa <marko@pacujo.net> - 2016-01-14 08:32 +0200

#101643 — Re: [Python-ideas] Password masking for getpass.getpass

On Thu, Jan 14, 2016 at 11:17 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Wed, Jan 13, 2016 at 3:19 AM, Chris Angelico <rosuav@gmail.com> wrote:
>> You're quite probably right that obfuscating the display is security
>> theatre; but it's the security theatre that people are expecting. If
>> you're about to enter your credit card details into a web form, does
>> it really matter whether or not the form itself was downloaded over an
>> encrypted link? But people are used to "look for the padlock", which
>> means that NOT having the padlock will bother people. If you ask for a
>> password and it gets displayed, people will wonder if they're entering
>> it in the right place.
>
> I realize that I'm taking this thread off-topic, but yes it's
> important that the form itself be downloaded over a secure connection.
> If I can MitM the form response over an insecure connection, then I
> can also MitM the form itself. And if I can do that, then I can
> deliver exactly the form you were expecting, but with an added script
> that will read your credit card number as you type it and then fire it
> off to be stored on my server before you've even hit the Submit
> button.

Noscript FTW.

:)

ChrisA

[toc] | [next] | [standalone]

#101648

On Thu, 14 Jan 2016 11:27 am, Chris Angelico wrote:

> On Thu, Jan 14, 2016 at 11:17 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:

>> I realize that I'm taking this thread off-topic, but yes it's
>> important that the form itself be downloaded over a secure connection.
>> If I can MitM the form response over an insecure connection, then I
>> can also MitM the form itself. And if I can do that, then I can
>> deliver exactly the form you were expecting, but with an added script
>> that will read your credit card number as you type it and then fire it
>> off to be stored on my server before you've even hit the Submit
>> button.
> 
> Noscript FTW.
> 
> :)


What of the poor souls who, for whatever reason, can't use NoScript?

What about those who are so frustrated with trying to get sites to work that
they just Allow All On This Page? I've seen websites that rely on anything
up to forty or fifty externally hosted scripts just to get basic
functionality. (I stopped counting after a while and just kept
clicking "Temporarily Allow...") You have external scripts calling out to
external scripts from completely different domains, each more and more
dodgy-looking than the last. And that's just the "legitimate" (for some
definition of) scripts.




-- 
Steven

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

#101651

On 01/13/2016 05:47 PM, Steven D'Aprano wrote:
> What of the poor souls who, for whatever reason, can't use NoScript?
> 
> What about those who are so frustrated with trying to get sites to work that
> they just Allow All On This Page? I've seen websites that rely on anything
> up to forty or fifty externally hosted scripts just to get basic
> functionality. (I stopped counting after a while and just kept
> clicking "Temporarily Allow...") You have external scripts calling out to
> external scripts from completely different domains, each more and more
> dodgy-looking than the last. And that's just the "legitimate" (for some
> definition of) scripts.

I seriously doubt there are any web pages that rely on 40 or 50 external
scripts for *basic* functionality.  But I have seen pages that load
dozens of external scripts for tracking, ad, and other purposes.  With
Ghostery I disable almost all of them and guess what, the pages load
faster and work just fine.  I think some companies must think, hey if
one analytics site is good, then 10 are better!  I've seen pages that
refused to load because some analytic script's hosting server was not
responding.  I highly recommend everyone run Ghostery and turn off
nearly all external scripts.  Doesn't usually affect the page's function
itself.  If anything it's educational to see how many external scripts
sites use these days. No wonder we have so many security issues.

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

#101670

Steven D'Aprano <steve@pearwood.info>:

> What about those who are so frustrated with trying to get sites to
> work that they just Allow All On This Page?

I'm occasionally frustrated by that, but I simply won't read that page.
Nothing truly important is lost.


Marko

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web