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 1 of 2  [1] 2  Next page →

#67328 — Password validation security issue

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] | [next] | [standalone]

#67332

On Sun, Mar 2, 2014 at 4:49 AM, Renato <rvernucio@gmail.com> wrote:
> 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?
>

Yeah, that's a pretty major issue, right there :)

The most common way to deal with this is to salt and hash your
passwords. While that might sound like a great thing to do to
potatoes, it's also the best way to stop your passwords from being
sniffed.

Best practice is to combine the password with the user name and with
some fixed text (the "salt"), and then run it through a
cryptographically secure hashing algorithm. In Python 2.7, you have
the hashlib module:

>>> import hashlib
>>> login = 'rosuav'
>>> password = 'xkcd936passwordgoeshere'
>>> encrypted = hashlib.sha256(login+'NaCl protects your passwords'+password).hexdigest()
>>> encrypted
'b329f2674af4d8d873e264d23713ace4505c211410eb46779c27e02d5a50466c'

Then all you store is that encrypted password. When the user enters
the login and password, you do the same operation, and compare it with
the stored hash; if they're the same, you accept the credentials.

The reason for including two pieces of salt (a constant and the user's
login) is that it ensures that duplicate passwords don't have
identical hashes, and that your set of password hashes are unique to
you (so someone can't have a "standard set of password hashes"). So
put some other string in between the two (or somewhere else in the
string - it doesn't matter how you put the pieces together, as long as
you're consistent).

Also, as hinted in the example above, encourage everyone to use XKCD
936 compliant passwords.

http://xkcd.com/936/

This is not a joke, this is not trivial. Using this scheme, you make
passwords that are orders of magnitude stronger than the classic
"minimum 8 characters, must include uppercase, lowercase, digit,
symbol". If that gives a theoretical 80 character corpus, then it's
insisting on a theoretical 50 bits of entropy (but, as the XKCD above
shows, it's more likely to be roughly half that); you can get pretty
much the same by using four common words at an estimated 11 bits per
word, which assumes you use a pool of just two thousand words. If your
pool's larger (if you use one or two less common words), you could be
looking at a corpus of 65536 words (my /usr/share/dict/words has more
than that), which would give you 64 bits of entropy from four words.
Bank style passwords are *weak*. Long passwords are strong.

So with truly strong passwords, and a hashing system that means an
attacker has to brute-force every possible password to figure out how
to get in, you can be confident that it's safe. But don't be naive;
still do your best to protect the password hashes from scrying eyes -
on Unix, you may be able to use a setuid binary to bounce into your
script, which could then be owned by and readable only by some other
user. Or, depending on how permissions are set up, you could arrange
it so any user may run 'sudo /usr/local/bin/yourscript.py', which
would then be freely able to read from a root-owned file of passwords.
But at this point, we're outside of Python code and into Unix
security, which is quite a different topic.

ChrisA

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

#67334

On 01.03.2014 19:11, Chris Angelico wrote:
> On Sun, Mar 2, 2014 at 4:49 AM, Renato <rvernucio@gmail.com> wrote:
>> 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?
>>
> 
> Yeah, that's a pretty major issue, right there :)
> 
> The most common way to deal with this is to salt and hash your
> passwords. While that might sound like a great thing to do to
> potatoes, it's also the best way to stop your passwords from being
> sniffed.
> 
> Best practice is to combine the password with the user name and with
> some fixed text (the "salt"), and then run it through a
> cryptographically secure hashing algorithm. In Python 2.7, you have
> the hashlib module:
> 
>>>> import hashlib
>>>> login = 'rosuav'
>>>> password = 'xkcd936passwordgoeshere'
>>>> encrypted = hashlib.sha256(login+'NaCl protects your passwords'+password).hexdigest()
>>>> encrypted
> 'b329f2674af4d8d873e264d23713ace4505c211410eb46779c27e02d5a50466c'

Please don't do that. It's insecure and not the proper way to handle
passwords. In fact it's insecure on so many levels that I don't know
where to start...

A hash function and a fixed salt are always the wrong way to handle
passwords. You must use a non-deterministic key stretching and key
derivation function with a salt from a CPRNG. For example PBKDF2
(usually used with HMAC as PRF), bcrypt or scrypt are well studied and
tune-able KDFs. You must also use a constant timing comparison function.

You don't have to do all the hard stuff on your own. I highly recommend
`passlib` to handle your passwords. It has a good API and is secure.

Christian

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

#67335

On 2014-03-02 05:11, Chris Angelico wrote:
> On Sun, Mar 2, 2014 at 4:49 AM, Renato <rvernucio@gmail.com> wrote:
> > My question is: is there a way of preventing the user from
> > reading the script's content?

Not really.  It might be a bit obfuscated, but 

>> Is there any strategy I could use to hide the passwords from the
>> users?

use Chris's suggestion about hashing.

That said, if the user has access to the source code, there's nothing
preventing them from changing

  if hash(provided_password) == existing_hash:
    do_magic()

into just

  if True:
    do_magic()

and re-running the program.

-tkc

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

#67336

On Sun, Mar 2, 2014 at 5:38 AM, Tim Chase <python.list@tim.thechases.com> wrote:
> That said, if the user has access to the source code, there's nothing
> preventing them from changing
>
>   if hash(provided_password) == existing_hash:
>     do_magic()
>
> into just
>
>   if True:
>     do_magic()
>
> and re-running the program.

They don't necessarily have to have the ability to edit the file.
Based on the original description, the problem is that if Python
running as that user can read the file (to run it), then so can
anything else running as that user. Python doesn't need to be able to
change the file.

ChrisA

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

#67337

On Sun, Mar 2, 2014 at 5:31 AM, Christian Heimes <christian@python.org> wrote:
>>>>> encrypted = hashlib.sha256(login+'NaCl protects your passwords'+password).hexdigest()
>>>>> encrypted
>> 'b329f2674af4d8d873e264d23713ace4505c211410eb46779c27e02d5a50466c'
>
> Please don't do that. It's insecure and not the proper way to handle
> passwords. In fact it's insecure on so many levels that I don't know
> where to start...

Please do start. This is an extremely common practice; are you able,
from just the information above, to figure out the password using
anything better than brute force?

ChrisA

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

#67345

On 01.03.2014 19:45, Chris Angelico wrote:
> On Sun, Mar 2, 2014 at 5:31 AM, Christian Heimes <christian@python.org> wrote:
>>>>>> encrypted = hashlib.sha256(login+'NaCl protects your passwords'+password).hexdigest()
>>>>>> encrypted
>>> 'b329f2674af4d8d873e264d23713ace4505c211410eb46779c27e02d5a50466c'
>>
>> Please don't do that. It's insecure and not the proper way to handle
>> passwords. In fact it's insecure on so many levels that I don't know
>> where to start...
> 
> Please do start. This is an extremely common practice; are you able,
> from just the information above, to figure out the password using
> anything better than brute force?

I'm aware that it's still a common technique. It makes me sad everytime
I see code that uses SHA256 for password hashing. :( Why haven't people
learnt from mistakes like LinkedIn's and Adobe's password disaster?

Yes, for most applications brute force is still the best option to crack
the password. Passwords are usually rather short, have a low entropy and
modern hardware is insanely fast. With software like [1] and a fast GPU
it is possible to do more than 10*10^9 checks/second for SHA-256.

Clever and very capable people have come up with algorithms like [2] to
make it much harder to crack passwords. The Wikipedia articles on KDF
and KSA explain both algorithm much better than I could. The PHC [3] is
a recent attempt to come up with an even more secure algorithm.

Please don't implement PBKDF2 on your own. Django, several other Python
libraries and OpenSSL did and made a really bad error that lead to a DoS
vulnerability.

Christian

[1] http://hashcat.net/oclhashcat/
[2] http://en.wikipedia.org/wiki/Key_derivation_function
[3] https://password-hashing.net/

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

#67373

In article <mailman.7533.1393703687.18130.python-list@python.org>,
 Christian Heimes <christian@python.org> wrote:

>  With software like [1] and a fast GPU
> it is possible to do more than 10*10^9 checks/second for SHA-256.

Just out of curiosity, how does that differ from 10^10 checks/second?

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

#67378

On 01.03.2014 21:25, Roy Smith wrote:
> In article <mailman.7533.1393703687.18130.python-list@python.org>,
>  Christian Heimes <christian@python.org> wrote:
> 
>>  With software like [1] and a fast GPU
>> it is possible to do more than 10*10^9 checks/second for SHA-256.
> 
> Just out of curiosity, how does that differ from 10^10 checks/second?


I find 10 * 10^9 easier to read because it has more resemblance to "10
billion". Next time I'll use the normalized scientific form 1.0e10. ;)

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

#67380

On Sun, Mar 2, 2014 at 9:07 AM, Christian Heimes <christian@python.org> wrote:
> On 01.03.2014 21:25, Roy Smith wrote:
>> In article <mailman.7533.1393703687.18130.python-list@python.org>,
>>  Christian Heimes <christian@python.org> wrote:
>>
>>>  With software like [1] and a fast GPU
>>> it is possible to do more than 10*10^9 checks/second for SHA-256.
>>
>> Just out of curiosity, how does that differ from 10^10 checks/second?
>
>
> I find 10 * 10^9 easier to read because it has more resemblance to "10
> billion". Next time I'll use the normalized scientific form 1.0e10. ;)

I wasn't sure if it ought to have been 10^9 or 10^10. In any case,
that makes only one order of magnitude of difference, and based on the
way I generate passwords, that still leaves it at 60-ish years of GPU
spinning. (It'd be 600 years at 10^9.)

ChrisA

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

#67347

On Sun, Mar 2, 2014 at 6:54 AM, Christian Heimes <christian@python.org> wrote:
> Yes, for most applications brute force is still the best option to crack
> the password. Passwords are usually rather short, have a low entropy and
> modern hardware is insanely fast. With software like [1] and a fast GPU
> it is possible to do more than 10*10^9 checks/second for SHA-256.

Using XKCD 936's estimate, 44 bits of entropy would still require
17592 seconds of processing at 10^9 per second. That's not a lot if
someone's personally targeting you *and* they know you use XKCD 936
*and* know the exact set of 2048 words that you drew your password
from *and* they know how you lay them out (spaces between, no spaces,
whether or not you capitalize the words, etc etc). Not knowing any of
these would add a few more bits of entropy; and if you use
/usr/share/dict/words and take only those words which consist entirely
of lower-case letters, then your corpus is over 65536 words [1], so
you have 64 bits of entropy. Even at 10^10 checks/second (which is
what 10*10^9 is, but that's an odd way to write it), that would be
21350 *days* of dedicated processing, just to crack the one password.
If cracking my password, and mine alone, in sixty years, is considered
"insanely fast", then I'm going to keep using SHA-256 for a while.

The problem isn't SHA-256. The problem is insecure passwords, the way
we've been taught to make them by the banks. Hence, XKCD 936.

ChrisA

[1] On my Debian Wheezy system:
$ grep -c '^[a-z]*$' /usr/share/dict/words
72861

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

#67462

On 01.03.2014 21:11, Chris Angelico wrote:
> The problem isn't SHA-256. The problem is insecure passwords, the way
> we've been taught to make them by the banks. Hence, XKCD 936.

Your argumentation is just wrong. You are saying "It's OK to use a
totally insecure way to hash passwords because passwords are insecure".
The point of KDF and KSA is to derive some token from a low entropy
source (human input) that makes an attack harder. Please do your reading
and trust secure experts on algorithms like PBKDF2, bcrypt and
scrypt. hash(salt + password) is outdated and proven to be insecure for
at least a decade, more like 15+ years.

The concept of passwords itself is insecure. But we are stuck with
passwords for authentication mechanism for the foreseeable future. 2FA
is an attempt to increase the security of passwords-based authentication
schemes.

Christian

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

#67465

In article <mailman.7592.1393788339.18130.python-list@python.org>,
 Christian Heimes <christian@python.org> wrote:

> On 01.03.2014 21:11, Chris Angelico wrote:
> > The problem isn't SHA-256. The problem is insecure passwords, the way
> > we've been taught to make them by the banks. Hence, XKCD 936.
> 
> Your argumentation is just wrong. You are saying "It's OK to use a
> totally insecure way to hash passwords because passwords are insecure".
> The point of KDF and KSA is to derive some token from a low entropy
> source (human input) that makes an attack harder. Please do your reading
> and trust secure experts on algorithms like PBKDF2, bcrypt and
> scrypt. hash(salt + password) is outdated and proven to be insecure for
> at least a decade, more like 15+ years.
> 
> The concept of passwords itself is insecure. But we are stuck with
> passwords for authentication mechanism for the foreseeable future. 2FA
> is an attempt to increase the security of passwords-based authentication
> schemes.
> 
> Christian

Security is as much about cryptography as it is about human factors and 
business drivers.  You can make things resistant to brute-force attacks 
by using longer keys, but people are still going to pick bad passwords.  
You can force them to pick "good" passwords by rejecting their first 37 
choices, but all that does is encourage them to write the passwords down 
on sticky notes.

And, yes, you can make things more secure with 2FA, but there's a cost 
there.  You have to purchase and manage the infrastructure.  More than 
that, there's lost business if potential customers prefer a competitor's 
product because it's easier to access.  Many of the known insecure 
systems we use today are not that way because the people who run them 
are stupid; they're that way because the people who run them have worked 
the numbers and decided the cost to implement more secure systems would 
exceed the risk exposure.

We recently got a frothing email from a user, which basically said, "You 
farking idiots, you emailed me my password in plain text!"  It turns 
out, his user name was the same as his password and what we had sent him 
(in response to an account recovery query) was his username.  In 
response to that, we altered our account generation process to forbid 
passwords which are too similar to your chosen username or email 
address.  Which, of course, means we've taken one more step down the 
road to forcing our users to write their passwords on sticky notes.

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

#67466

On Mon, Mar 3, 2014 at 7:01 AM, Roy Smith <roy@panix.com> wrote:
> We recently got a frothing email from a user, which basically said, "You
> farking idiots, you emailed me my password in plain text!"  It turns
> out, his user name was the same as his password and what we had sent him
> (in response to an account recovery query) was his username.

Sadly, there *are* systems that will actually email passwords in plain
text, and don't tell you so beforehand (Mailman at least tells you
that the password isn't meant for security). I met one recently. Did
not appreciate that. Fortunately when I changed my password, the new
password wasn't emailed back to me.

ChrisA

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

#67492

On Sun, 02 Mar 2014 15:01:09 -0500, Roy Smith wrote:

> Security is as much about cryptography as it is about human factors and
> business drivers.  You can make things resistant to brute-force attacks
> by using longer keys, but people are still going to pick bad passwords.

Yes. But:

> You can force them to pick "good" passwords by rejecting their first 37
> choices, but all that does is encourage them to write the passwords down
> on sticky notes.

There is nothing wrong with writing passwords down on sticky notes. 
(Well, figuratively speaking. Perhaps not *literal* sticky notes, since 
they are too easy to lose.) You have to ask, what is the threat you are 
trying to defend against?

If your threat is that the Secret Police will break your door down at 
3am, and smash your fingers one at a time until you give them your 
passwords, then strong passwords that only you remember will not save you.

If the threat is that your little brother will log into your hotmail 
account and send rude messages to your school friends, then writing your 
password down on a Postit and sticking it on the computer is insecure, 
but keeping it in your wallet or purse may be secure enough.

Today, one of the biggest (but not the only) threats most people face is 
the mass theft of passwords from idiot organisations that store them in 
insecure databases as plain text. There's not much we, the users, can do 
about that, except complain complain complain when it happens. Possibly 
sue, on the basis that storing passwords as plain text is not within a 
million miles of best practice or even standard practice.

Another threat comes from black-hat hackers breaking your password. 
Whether they want *your* password specifically, or just picked your 
account randomly, this is where strong passwords can have a good effect. 
Until such time as an attacker can reach through the Internet to read the 
password on your Postit Note, writing down your strong password and 
keeping it by your computer is an effective way to counter this threat.


> And, yes, you can make things more secure with 2FA, but there's a cost
> there.  You have to purchase and manage the infrastructure.  More than
> that, there's lost business if potential customers prefer a competitor's
> product because it's easier to access.  Many of the known insecure
> systems we use today are not that way because the people who run them
> are stupid; they're that way because the people who run them have worked
> the numbers and decided the cost to implement more secure systems would
> exceed the risk exposure.

While in principle you are right, in practice I think that most of these 
people and organisations start from number of dodgy assumptions, starting 
with "Meh, it'll never happen...". They underestimate the risk, 
underestimate the consequences, ignore costs that don't apply solely to 
them (e.g. the cost of spam sent from tens of millions of compromised PCs 
and gmail accounts), overestimate the strength of their half-baked 
solutions, and ignore the portion of their user-base who actually does 
want better security.

When they do make a half-hearted attempt at security, it's often security 
theatre, e.g. I have a bank account with one bank that doesn't let you 
type your password, instead you have to click keys on a simulated 
keyboard on screen. You're limited to *six* (SIX!!!) case-insensitive 
alphanumeric characters, letters and digits only.

And then, to add insult to injury, they have the fecking cheek to hassle 
you every few months to change your insecure password for another 
insecure password, thus increasing the chance that you'll forgot what it 
is and lock yourself out of the account. This encourages people to choose 
even weaker passwords, so they won't forget them.

Another bank I use eschews such ridiculous "security" and actually 
provides you with a real cryptographic key for which you have to provide 
a passphrase. A passphrase limited to *eight* alphanumeric characters. 
And I think it is case-insensitive, although I haven't actually tried it.

I expect that these idiots spent more time, effort and money *preventing* 
their users from putting in strong passwords than they would have spent 
to allow strong passwords.

 
> We recently got a frothing email from a user, which basically said, "You
> farking idiots, you emailed me my password in plain text!"  It turns
> out, his user name was the same as his password and what we had sent him
> (in response to an account recovery query) was his username.  In
> response to that, we altered our account generation process to forbid
> passwords which are too similar to your chosen username or email
> address.  Which, of course, means we've taken one more step down the
> road to forcing our users to write their passwords on sticky notes.

That's a good thing.

People have managed physical keys for *centuries*. Yes, there are a class 
of threats where you lose your key, or someone steals it, or makes a 
copy, but the risks are well-understood and can be managed even by your 
grandmother. We have good solutions for those problems that work well, 
and many of them apply just as well to sticky notes with secure passwords 
written on them.



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

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

#67503

On Sun, Mar 2, 2014 at 6:16 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> People have managed physical keys for *centuries*. Yes, there are a class
> of threats where you lose your key, or someone steals it, or makes a
> copy, but the risks are well-understood and can be managed even by your
> grandmother. We have good solutions for those problems that work well,
> and many of them apply just as well to sticky notes with secure passwords
> written on them.

I don't know how well the analogy holds up.  People protect their
keys, because a) if they lose them, they can't get into their house or
business, and b) if they're stolen, somebody else could gain access
and steal expensive items from them.  People are less likely to
protect their sticky notes, because a) nobody is going to steal a
piece of paper, and b) if it does go missing, the IT guy is just one
phone call away, and c) who would want to break into my desktop
anyway? I don't have any trade secrets in there.

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

#67508

On Sun, 02 Mar 2014 18:52:40 -0700, Ian Kelly wrote:

> On Sun, Mar 2, 2014 at 6:16 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> People have managed physical keys for *centuries*. Yes, there are a
>> class of threats where you lose your key, or someone steals it, or
>> makes a copy, but the risks are well-understood and can be managed even
>> by your grandmother. We have good solutions for those problems that
>> work well, and many of them apply just as well to sticky notes with
>> secure passwords written on them.
> 
> I don't know how well the analogy holds up.  People protect their keys,
> because a) if they lose them, they can't get into their house or
> business, and b) if they're stolen, somebody else could gain access and
> steal expensive items from them. 

A bit like the password to your bank account, or for that matter your 
Facebook account.


> People are less likely to protect
> their sticky notes, because a) nobody is going to steal a piece of
> paper, 

Oh really? Chances are you're wallet is *full* of pieces of paper that 
people would steal, given half the chance.


> and b) if it does go missing, the IT guy is just one phone call
> away, 

Last time I had to call my bank to unlock my account, it took two phone 
calls and nearly three hours of elapsed time. And I was lucky I didn't 
have to physically go in to a branch and show photo ID.


> and c) who would want to break into my desktop anyway? I don't
> have any trade secrets in there.

Who would want to steal somebody else's identity?

I'm not saying that people are born with an intuitive understanding of 
the security issues of a modern technological society. But they can 
*learn* (perhaps only after they get burned) that they need to protect 
their computer accounts, including their desktop.

Having learned that, they're screwed: even in the (uncommon) case that 
their account will support a cryptographically strong passphrase, most 
people need a dozen or more different passwords and/or passphrases. (I 
have about 50, only a dozen of which I keep in my head.) Who is going to 
remember a 12 character high-entropy string for an account they only use 
once a year? Most people have trouble remembering four-digit PINs if they 
don't use them regularly.

We cannot solve the social problem that people *don't* care about 
security with a technical solution, but we might be able to solve the 
problem that people *can't* remember sufficient passphrases and passwords 
for their needs. Lacking a technical solution for that, for most people, 
under many practical threat models, writing down your strong passwords on 
bits of paper which you then keep safe is better than using weak 
passwords, using one strong password for everything, or trying to 
remember a dozen strong, independent passwords.



-- 
Steven

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

#67510

On Mon, Mar 3, 2014 at 3:38 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> Oh really? Chances are you're wallet is *full* of pieces of paper that
> people would steal, given half the chance.

Alas no... around here, wallets get filled with pieces of plastic [1],
of which my wallet is sadly devoid. And I can't imagine anyone putting
effort into stealing my Gilbert & Sullivan Society membership card,
nor my coupon card for a half-price watch battery replacement on
condition that I take it back to some place that I don't go anywhere
near any more... But don't let that detract from your point :D

>> and b) if it does go missing, the IT guy is just one phone call
>> away,
>
> Last time I had to call my bank to unlock my account, it took two phone
> calls and nearly three hours of elapsed time. And I was lucky I didn't
> have to physically go in to a branch and show photo ID.

That's about par for the course. Worst part of it is when you lose
your connection and have to (a) go right back to the end of the caller
queue, (b) get through to a different agent, and therefore (c) have to
start over with the whole identifying-yourself thing. I wish I could
invoke tmux or GNU Screen on arrival,and then just reconnect.

This is, perhaps, the best argument in favour of password security.
The thought that someone might steal your identity is so vague and
hard to comprehend that it won't scare people; the possibility of
someone stealing money is "Oh but my bank will keep me safe" (whether
or not that's true is quite tangential); but explain that forgetting
your password (or having someone else figure out your password) means
having to call support? *That* is an incentive.

> Having learned that, they're screwed: even in the (uncommon) case that
> their account will support a cryptographically strong passphrase, most
> people need a dozen or more different passwords and/or passphrases. (I
> have about 50, only a dozen of which I keep in my head.) Who is going to
> remember a 12 character high-entropy string for an account they only use
> once a year? Most people have trouble remembering four-digit PINs if they
> don't use them regularly.

What if you create XKCD 936 passwords, and then have one "master
password file" in which you store, for each password, four words that
are synonyms for the originals, plus the first letters of them?
(Obviously your master password file (a) never leaves your own
computer, and (b) should itself be encrypted with some secure
password, and treated with extreme sensitivity. But that gets around
the "once a year" problem, as you'll refer to this one file any time
you need to check any of your rare passwords.) As a second line of
defense before contacting support, it feels plausible, but I've never
actually had an opportunity to try it.

Of course, the whole concept depends on being able to use long
memorable passwords. Any system that sets a maximum password length of
anything less than about 30-40 characters is causing its users
problems. There's almost never any reason to set a maximum at all.

ChrisA

[1] http://en.wikipedia.org/wiki/Polymer_banknote

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

#67513

On Sun, Mar 2, 2014 at 10:44 PM, Chris Angelico <rosuav@gmail.com> wrote:
> Of course, the whole concept depends on being able to use long
> memorable passwords. Any system that sets a maximum password length of
> anything less than about 30-40 characters is causing its users
> problems. There's almost never any reason to set a maximum at all.

Well, there's usually *some* reason.  If you allow your users to set a
100-MB password then your system has to accept and attempt to verify
any 100-MB passwords that might get passed in, which opens you up to a
certain DoS attack.  Setting the limit at 8 characters though is
absurd and a probable indication of bad password handling.

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

#67504

On Mon, Mar 3, 2014 at 12:52 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Sun, Mar 2, 2014 at 6:16 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> People have managed physical keys for *centuries*. Yes, there are a class
>> of threats where you lose your key, or someone steals it, or makes a
>> copy, but the risks are well-understood and can be managed even by your
>> grandmother. We have good solutions for those problems that work well,
>> and many of them apply just as well to sticky notes with secure passwords
>> written on them.
>
> I don't know how well the analogy holds up.  People protect their
> keys, because a) if they lose them, they can't get into their house or
> business, and b) if they're stolen, somebody else could gain access
> and steal expensive items from them.  People are less likely to
> protect their sticky notes, because a) nobody is going to steal a
> piece of paper, and b) if it does go missing, the IT guy is just one
> phone call away, and c) who would want to break into my desktop
> anyway? I don't have any trade secrets in there.

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.)
Ultimately, any network-accessible resource is protected by some
system of credentials that can be guessed; the only question is how
hard it is to guess. Any scheme to steal the password has to be easier
than guessing, or it's not worth it. Breaking a salted SHA-256 versus
XKCD 538 password cracking? Take your pick, but guessing a
six-character password beats both (being quicker than the one and more
subtle than the other).

Maybe salted SHA-256 isn't perfect, but it's certainly (a) a lot
better than plain text, unsalted hashes, or salted MD5, and (b) good
enough to raise the cracking of the hash above a lot of other
infiltration techniques.

ChrisA

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web