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

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

Password validation security issue

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

Contents

  Password validation security issue Renato <rvernucio@gmail.com> - 2014-03-01 09:49 -0800
    Re: Password validation security issue Chris Angelico <rosuav@gmail.com> - 2014-03-02 05:11 +1100
    Re: Password validation security issue Christian Heimes <christian@python.org> - 2014-03-01 19:31 +0100
    Re: Password validation security issue Tim Chase <python.list@tim.thechases.com> - 2014-03-01 12:38 -0600
    Re: Password validation security issue Chris Angelico <rosuav@gmail.com> - 2014-03-02 05:43 +1100
    Re: Password validation security issue Chris Angelico <rosuav@gmail.com> - 2014-03-02 05:45 +1100
    Re: Password validation security issue Christian Heimes <christian@python.org> - 2014-03-01 20:54 +0100
      Re: Password validation security issue Roy Smith <roy@panix.com> - 2014-03-01 15:25 -0500
        Re: Password validation security issue Christian Heimes <christian@python.org> - 2014-03-01 23:07 +0100
        Re: Password validation security issue Chris Angelico <rosuav@gmail.com> - 2014-03-02 09:13 +1100
    Re: Password validation security issue Chris Angelico <rosuav@gmail.com> - 2014-03-02 07:11 +1100
    Re: Password validation security issue Christian Heimes <christian@python.org> - 2014-03-02 20:25 +0100
      Re: Password validation security issue Roy Smith <roy@panix.com> - 2014-03-02 15:01 -0500
        Re: Password validation security issue Chris Angelico <rosuav@gmail.com> - 2014-03-03 07:32 +1100
        Re: Password validation security issue Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-03 01:16 +0000
          Re: Password validation security issue Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-02 18:52 -0700
            Re: Password validation security issue Steven D'Aprano <steve@pearwood.info> - 2014-03-03 04:38 +0000
              Re: Password validation security issue Chris Angelico <rosuav@gmail.com> - 2014-03-03 16:44 +1100
              Re: Password validation security issue Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-02 23:50 -0700
          Re: Password validation security issue Chris Angelico <rosuav@gmail.com> - 2014-03-03 13:56 +1100
            Re: Password validation security issue Roy Smith <roy@panix.com> - 2014-03-03 08:41 -0500
              Re: Password validation security issue Chris Angelico <rosuav@gmail.com> - 2014-03-04 00:55 +1100
                Re: Password validation security issue Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-03 16:46 +0000
                  Re: Password validation security issue Chris Angelico <rosuav@gmail.com> - 2014-03-04 05:46 +1100
              Re: Password validation security issue MRAB <python@mrabarnett.plus.com> - 2014-03-03 16:29 +0000
              Re: Password validation security issue Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-03 17:41 +0000
    Re: Password validation security issue Renato <rvernucio@gmail.com> - 2014-03-02 15:10 -0800
      Re: Password validation security issue Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-02 18:49 -0700
      Re: Password validation security issue Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-03 02:30 +0000

Page 2 of 2 — ← Prev page 1 [2]

#67540

In article <mailman.7619.1393815421.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> The greatest threats these days are from the network, not from someone
> physically walking into an office. (That said, though, the low-hanging
> fruit from walking into an office can be *extremely* tempting. Pulling
> off a basic password leech off sticky notes is often so easy that it
> can be done as a visitor, or at least as a pizza deliveryman.)

Doesn't even require physical presence.  With the ubiquity of various 
video chat applications, as long as the sticky note is in the field of 
view of the camera, you've leaked the password.  With the right 
lighting, I wouldn't be surprised if you could pick up the reflection of 
a sticky note in somebody's eyeglasses.

So, here's my own (embarrassing) story of password leaking.  Back when 
smartphones were new, I had one of the early Palm Treos.  I decided a 
good place to store my passwords was as fields on my own card.  What I 
didn't realize was that if I beamed[*] my card to somebody, I was also 
giving them all my passwords, mostly because it had never occurred to me 
that I might want to beam my card to somebody.  Until somebody else in 
my office got another smart phone that had beaming capabilities and we 
decided to see how it worked.  It occurred to me as soon as we completed 
the first experiment.

I used to work at <big company> which had a typical big company IT 
department which enforced all sorts of annoying pseudo-security rules.  
As far as I could figure out, however, all you needed to get them to 
reset anybody's password and tell you the new one was to know their 
employee ID number (visible on the front of their ID badge), and to make 
the call from their desk phone.

[*] Beaming: a prehistoric technology which allows exchange of data over 
an infrared light beam.

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

#67545

On Tue, Mar 4, 2014 at 12:41 AM, Roy Smith <roy@panix.com> wrote:
> I used to work at <big company> which had a typical big company IT
> department which enforced all sorts of annoying pseudo-security rules.
> As far as I could figure out, however, all you needed to get them to
> reset anybody's password and tell you the new one was to know their
> employee ID number (visible on the front of their ID badge), and to make
> the call from their desk phone.

Technically, that's a separate vulnerability. If you figure out
someone else's password, you can log in as that person and nobody is
any the wiser (bar detailed logs eg of IP addresses). Getting a
password reset will at least alert the person on their next login.
That may or may not be safe, of course. Doing a password reset at
4:30pm the day before someone goes away for two months might give you
free reign for that time *and* might not even arouse suspicions ("I
can't remember my password after the break, can you reset it
please?").

But it's an attack vector that MUST be considered, which is why I
never tell the truth in any "secret question / secret answer" boxes.
Why some sites think "mother's maiden name" is at all safe is beyond
my comprehension. And that's not counting the ones that I can't answer
because I can't find the "NaN" key on my keyboard, like "Surname of
first girlfriend". *twiddle thumbs*

ChrisA

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

#67565

On Tue, 04 Mar 2014 00:55:45 +1100, Chris Angelico wrote:

> But it's an attack vector that MUST be considered, which is why I never
> tell the truth in any "secret question / secret answer" boxes. Why some
> sites think "mother's maiden name" is at all safe is beyond my
> comprehension. And that's not counting the ones that I can't answer
> because I can't find the "NaN" key on my keyboard, like "Surname of
> first girlfriend". *twiddle thumbs*

If you lie to these secret questions -- and I strongly recommend that you 
do -- you should record the answers somewhere so you can retrieve them 
later, long after you've forgotten whether the name of your first pet was 
Obama bin Bush or Tarzan the King of the Desert. Trust me on this, you 
will need them.

The missus has a Yahoo account, and being paranoid even by my standards 
for keeping her web presence completely separate from her real life, she 
invented fake answers to the secret questions like Your Birthday. (As you 
should. It is my opinion that lying to big faceless corporations is not a 
sin, but a duty. They are not on your side, and the more they know about 
you the more they will abuse the knowledge.) So fast forward a few 
months, and the Yahoos at Yahoo put through another bloody round of 
bloody so-called improvements that break everything in sight, including 
people's passwords. So She Who Must Be Obeyed resets her password, except 
now it's *permanently broken* -- no matter how many times she resets her 
password, Yahoo will let her log in *once* then the next time claim the 
password is invalid. 

And then a week or two ago, Yahoo added another piece of broken security 
theatre, and ask you to answer one of those secret questions before 
they'll reset your password. So now SWMBO is locked out of her account 
because she can't remember what she used.

Mind you, Yahoo is rapidly going from Worse to Even Worse, so it was only 
a matter of time before she would have dumped them for good. Still, it's 
annoying -- it's like having your identity stolen by a hermit on some 
mountain top who doesn't do anything with it, except prevent you from 
using it.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

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

#67572

On Tue, Mar 4, 2014 at 3:46 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 04 Mar 2014 00:55:45 +1100, Chris Angelico wrote:
>
>> But it's an attack vector that MUST be considered, which is why I never
>> tell the truth in any "secret question / secret answer" boxes. Why some
>> sites think "mother's maiden name" is at all safe is beyond my
>> comprehension. And that's not counting the ones that I can't answer
>> because I can't find the "NaN" key on my keyboard, like "Surname of
>> first girlfriend". *twiddle thumbs*
>
> If you lie to these secret questions -- and I strongly recommend that you
> do -- you should record the answers somewhere so you can retrieve them
> later, long after you've forgotten whether the name of your first pet was
> Obama bin Bush or Tarzan the King of the Desert. Trust me on this, you
> will need them.
>
> The missus has a Yahoo account, and being paranoid even by my standards
> for keeping her web presence completely separate from her real life, she
> invented fake answers to the secret questions like Your Birthday. (As you
> should. It is my opinion that lying to big faceless corporations is not a
> sin, but a duty. They are not on your side, and the more they know about
> you the more they will abuse the knowledge.)

I've followed this for a long time. If anything asks for my date of
birth and appears to be just verifying that I'm at least 13 years old,
I'll say Jan 1st in some year that's vaguely near my year of birth.
(This is largely because the drop down combo boxes usually already say
Jan 1st, and it's pointlessly tedious to aim for my exact year, much
less the day within that.) My brother's new wife (married last Nov)
didn't understand this about me when I was helping her port her mobile
phone onto the family account. The system asks me for a date of birth,
and I turn to her and say, "What date of birth did you use?" - and she
looks at me funny, not understanding why I don't already know what to
fill in. But for all I know, she could have set up her mobile account
with a DOB of 1912/6/23 in commemoration of cryptography.

But yes, on the (frequent) occasions when I lie through my teeth, I
usually record my answers as separate passwords.

ChrisA

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

#67563

On 2014-03-03 13:55, Chris Angelico wrote:
> On Tue, Mar 4, 2014 at 12:41 AM, Roy Smith <roy@panix.com> wrote:
>> I used to work at <big company> which had a typical big company IT
>> department which enforced all sorts of annoying pseudo-security rules.
>> As far as I could figure out, however, all you needed to get them to
>> reset anybody's password and tell you the new one was to know their
>> employee ID number (visible on the front of their ID badge), and to make
>> the call from their desk phone.
>
> Technically, that's a separate vulnerability. If you figure out
> someone else's password, you can log in as that person and nobody is
> any the wiser (bar detailed logs eg of IP addresses). Getting a
> password reset will at least alert the person on their next login.
> That may or may not be safe, of course. Doing a password reset at
> 4:30pm the day before someone goes away for two months might give you
> free reign for that time *and* might not even arouse suspicions ("I
> can't remember my password after the break, can you reset it
> please?").
>
> But it's an attack vector that MUST be considered, which is why I
> never tell the truth in any "secret question / secret answer" boxes.
> Why some sites think "mother's maiden name" is at all safe is beyond
> my comprehension. And that's not counting the ones that I can't answer
> because I can't find the "NaN" key on my keyboard, like "Surname of
> first girlfriend". *twiddle thumbs*
>
I don't think you're obliged to answer such questions truthfully.

Q: Surname of first girlfriend?
A: Luxury Yacht

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

#67569

On Mon, 03 Mar 2014 08:41:10 -0500, Roy Smith wrote:

> In article <mailman.7619.1393815421.18130.python-list@python.org>,
>  Chris Angelico <rosuav@gmail.com> wrote:
> 
>> The greatest threats these days are from the network, not from someone
>> physically walking into an office. (That said, though, the low-hanging
>> fruit from walking into an office can be *extremely* tempting. Pulling
>> off a basic password leech off sticky notes is often so easy that it
>> can be done as a visitor, or at least as a pizza deliveryman.)
> 
> Doesn't even require physical presence.  With the ubiquity of various
> video chat applications, as long as the sticky note is in the field of
> view of the camera, you've leaked the password.  With the right
> lighting, I wouldn't be surprised if you could pick up the reflection of
> a sticky note in somebody's eyeglasses.

Let's see now... 

- one in a ten thousand chance that somebody will hack my account because 
it has a weak password; versus

- one in a thousand million chance that somebody will view my strong 
password reflected in my glasses and be able to identify what account 
name for which system it goes with, and be the sort of opportunistic 
black-hat who will use it to break into my account.

Nobody is saying that writing passwords down is secure against every and 
any possible attack. (When the Secret Police smash your door down at 3am, 
you probably won't have time to eat the passwords, even if you remembered 
to print them on rice paper instead of a sticky note.) The concept is 
that writing down strong passwords is preferable to remembering weak 
passwords given the typical threats most people are exposed to.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

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

#67477

I would like to thank every one who posted a reply. I learnt a lot from you, guys! I appreciate your attention and your help :)

I took a class on Computer Simulation last year. It was told that deterministic (pseudo-)random numbers are excellent for simulations, because they allow debugging and replication when using a seed(). But it was said that deterministic random numbers weren't indeed suitable for encryption and security issues in general. For this purpose, non-deterministc stochastic methods would be more indicated. I learnt a lot about deterministic random numbers generation in this course, like using Mersenne Twister algorithm, but I learnt nothing about encryption, since it wasn't in the scope of that course. Could you suggest some introductory material concerning encryption? I have an intermediate math background (calculus, linear algebra etc) and I'm willing to learn more about security matters.

One last thing, about my original question. So, the only way of encapsulating a Python script content is to code a simple binary program to call it?

Regards,
Renato


Em sábado, 1 de março de 2014 14h49min49s UTC-3, Renato  escreveu:
> Hello everybody, I implemented a password validation with a Python 2.7.5 script in OpenSUSE 13.1. The user calls it passing 'login' and 'password' as arguments. I made a dictionary in the format hashtable = {'login':'password'} and I use this hash table to compare the 'login' and 'password' that were passed in order to validate them. The problem is that any user who can execute the script will be able to read it too (since it must be read by python's interpreter), and this is causing some security issues since any user can access all other users' passwords if he opens this script and reads the code.
> 
> 
> 
> My question is: is there a way of preventing the user from reading the script's content? Is there any strategy I could use to hide the passwords from the users?

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

#67498

On Sun, Mar 2, 2014 at 4:10 PM, Renato <rvernucio@gmail.com> wrote:
> I would like to thank every one who posted a reply. I learnt a lot from you, guys! I appreciate your attention and your help :)
>
> I took a class on Computer Simulation last year. It was told that deterministic (pseudo-)random numbers are excellent for simulations, because they allow debugging and replication when using a seed(). But it was said that deterministic random numbers weren't indeed suitable for encryption and security issues in general. For this purpose, non-deterministc stochastic methods would be more indicated. I learnt a lot about deterministic random numbers generation in this course, like using Mersenne Twister algorithm, but I learnt nothing about encryption, since it wasn't in the scope of that course. Could you suggest some introductory material concerning encryption? I have an intermediate math background (calculus, linear algebra etc) and I'm willing to learn more about security matters.
>
> One last thing, about my original question. So, the only way of encapsulating a Python script content is to code a simple binary program to call it?

Another alternative would be to implement the script as a service that
runs under a separate account.  All the user can directly access is a
client script that sends requests to the service, which does the
actual work and is effectively encapsulated.

I'll also reiterate what others have written about protecting
passwords.  No matter how much you think you've locked down the
script, you shouldn't be storing plaintext passwords *anywhere*.
Remember that nothing that you code will ever be as secure as you
think it is.

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

#67502

On Sun, 02 Mar 2014 15:10:06 -0800, Renato wrote:

> I would like to thank every one who posted a reply. I learnt a lot from
> you, guys! I appreciate your attention and your help :)
> 
> I took a class on Computer Simulation last year. It was told that
> deterministic (pseudo-)random numbers are excellent for simulations,
> because they allow debugging and replication when using a seed(). But it
> was said that deterministic random numbers weren't indeed suitable for
> encryption and security issues in general. For this purpose,
> non-deterministc stochastic methods would be more indicated. 

Either you have misunderstood, or you have been told something incorrect.

You don't in general want non-deterministic stochastic randomness, 
because you can't control it and you can't make any guarantees about it. 
Stochastic randomness nearly always has deviations from uniformity which 
can be exploited, that is, it is less random than you might think. For 
example:

http://www.newscientist.com/article/mg21428644.500-roulette-beater-spills-
physics-behind-victory.html

http://en.wikipedia.org/wiki/Eudaemons


Nor do should you use deterministic PRNGs like the Mersenne Twister, not 
because they are deterministic, but because they aren't cryptographically 
strong.

The right approach is to use a deterministic PRNG which is deliberately 
designed for use in cryptographic applications, and then add in a source 
of entropy (which might be non-deterministic, like thermal noise or the 
output of radioactive decay). On Unix systems, the OS already does this 
for you:

http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/


> One last thing, about my original question. So, the only way of
> encapsulating a Python script content is to code a simple binary program
> to call it?

I don't understand this question. Can you explain more?




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web