Password validation security issue

[Renato]

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?

 

[Chris Angelico]

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' thatwere 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 readsthe 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:
'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

 

[Tim Chase]

Not really. It might be a bit obfuscated, but

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

 

[Chris Angelico]

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

 

[Chris Angelico]

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

 

[Roy Smith]

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?

 

[Roy Smith]

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.

 

[Chris Angelico]

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

 

[Renato]

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 methodswould be more indicated. I learnt a lot about deterministic random numbersgeneration 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 havean 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:

 

[Steven D'Aprano]

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.

 

[Ian Kelly]

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.

 

[Steven D'Aprano]

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?

 

[Chris Angelico]

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

 

[Steven D'Aprano]

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.

 

[Chris Angelico]

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

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

 

[Ian Kelly]

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.

 

[Roy Smith]

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.

 

[MRAB]

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

 

[Steven D'Aprano]

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]

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.