General Password questions

[Todd Johnson]

I am creating a dialog in wxPython for log in
purposes. Basically when the user clicks the ok
button, the dialog box saves the user name and
password as class attributes. Then as long as the
dialog exists calling MyDialog.GetUserName() and
MyDialog.GetPassword() returns them. This seems
insecure to me. Is there a better way to go about this
or is it safe as long as I destroy the dialog as soon
as I am done with it?

On a similar note, I want to save the password to a
file. How do I encrypt the password? I assume straight
binary is too easy to reverse engineer though my
program isn't really saving any vital information so
it may be acceptable. Any ideas or links would be very
appreciated.

Thanks in advance,
Todd A. Johnson

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

[Peter Hansen]

Todd Johnson wrote:

I am creating a dialog in wxPython for log in
purposes. Basically when the user clicks the ok
button, the dialog box saves the user name and
password as class attributes. Then as long as the
dialog exists calling MyDialog.GetUserName() and
MyDialog.GetPassword() returns them. This seems
insecure to me.
Why do you feel it's insecure?
On a similar note, I want to save the password to a
file. How do I encrypt the password?

You don't encrypt passwords, you hash them. That means use a
cryptographically strong hashing algorithm such as SHA or MD5
and store the resulting value. Later, when a user has entered
a password which you want to check against the correct one, you
run the same hash algorithm on the password-under-test and compare
the result with the stored result. The hash algorithm is designed
so that it's computationally infeasible to reverse-engineer a
password that corresponds to a given hash value, making it about
as good as storing the real thing without the insecurity in
that approach. Luckily, these algorithms are already implemented
for you so you don't need to deal with the complexities.

Note, however, the likelihood that somebody interested in
cracking this whole system could easily do things like change
the Python source, or modify the password file that contains the
hash value, substituting their own pre-calculated hash which
matches the password they wish to enter.

Assuming you are just trying to prevent casual intrusion and
there's really nothing valuable involved, a simple hash using
the sha or md5 module would probably do fine. Of course, at this
point I fully expect a dozen people with more background in
security to start stomping all over this advice and tell you
how wrong it is, but I live to provide people with that kind of
opportunity. ;-)

I encourage you to learn more about this, too, by searching the
web or something. Time spent studying security issues will always
repay itself, no matter your current level of expertise...

-Peter

[Riccardo Attilio Galli]

On Mon, 22 Sep 2003 19:32:50 -0400, Peter Hansen wrote:

Todd Johnson wrote:

On a similar note, I want to save the password to a
file. How do I encrypt the password?

You don't encrypt passwords, you hash them. That means use a
cryptographically strong hashing algorithm such as SHA or MD5
and store the resulting value. Later, when a user has entered
a password which you want to check against the correct one, you
run the same hash algorithm on the password-under-test and compare
the result with the stored result.
[...]
-Peter

Hi Peter,
what about if I would reload an entered password?
I wrote an e-mail client, and I haven't found a way to store the password
that an user enter the first time and use it when the program is restarted.
I don't want to ask to the user every time the account password, but also
I don't want to store it as plain text.
Do you know what is the usual practice in these cases?

Thanks,
Riccardo

--
-=Riccardo Galli=-

_,e.
s~ ``
~@. ideralis Programs
.. ol
`**~ http://www.sideralis.net

[Peter Hansen]

Riccardo Attilio Galli wrote:

On Mon, 22 Sep 2003 19:32:50 -0400, Peter Hansen wrote:

Todd Johnson wrote:

On a similar note, I want to save the password to a
file. How do I encrypt the password?

You don't encrypt passwords, you hash them. That means use a
cryptographically strong hashing algorithm such as SHA or MD5
and store the resulting value. Later, when a user has entered
a password which you want to check against the correct one, you
run the same hash algorithm on the password-under-test and compare
the result with the stored result.
[...]

what about if I would reload an entered password?
I wrote an e-mail client, and I haven't found a way to store the password
that an user enter the first time and use it when the program is restarted.
I don't want to ask to the user every time the account password, but also
I don't want to store it as plain text.
Do you know what is the usual practice in these cases?

As near as I can understand your questions, the approach I provided
solves all these issues. You need to do a little research into this
stuff on the web, or do some experimentation, before you'll understand
it well enough to use it, perhaps.

In a nutshell, this is the point: you never use the plaintext form of
the password. As soon as it is entered, you convert it to a hash. You
store the hash, and if a user later enters a password and you need to
check it, you convert *it* to a hash and compare the hashes. Never,
ever, store or compare plain text passwords. Does that help?

-Peter

[Richard Brodie]

"Riccardo Attilio Galli" <ri*****@riquito.matrix> wrote in message
news:pa****************************@riquito.matrix ...

On Mon, 22 Sep 2003 19:32:50 -0400, Peter Hansen wrote: I don't want to ask to the user every time the account password, but also
I don't want to store it as plain text. Do you know what is the usual practice in these cases?

The usual practice is to store the password in some trivially breakable encryption
scheme, preserving some illusion of security.

[Peter Hansen]

Richard Brodie wrote:

"Riccardo Attilio Galli" <ri*****@riquito.matrix> wrote in message
news:pa****************************@riquito.matrix ...

On Mon, 22 Sep 2003 19:32:50 -0400, Peter Hansen wrote:

I don't want to ask to the user every time the account password, but also
I don't want to store it as plain text.

Do you know what is the usual practice in these cases?

The usual practice is to store the password in some trivially breakable encryption
scheme, preserving some illusion of security.

Hah! :-) True... sadly.

I'll say what I said a moment ago in the other response, but in a different way.

If it is possible to retrieve the plaintext password, whether because it was
stored in plaintext or because it was stored with some trivially breakable
encryption scheme (or even if it was stored with an incredibly sophisticated
encyprtion scheme), the system is broken. Nobody, adminstrators included,
should ever be able to retrieve the plaintext password of a user, and even with
a fancy encryption scheme, there is always a separate password or key which
can be used to reverse the encryption.

Use hashes.

-Peter

[Riccardo Attilio Galli]

On Tue, 23 Sep 2003 09:28:49 -0400, Peter Hansen wrote:

Riccardo Attilio Galli wrote:

what about if I would reload an entered password?
I wrote an e-mail client, and I haven't found a way to store the password
that an user enter the first time and use it when the program is restarted.
I don't want to ask to the user every time the account password, but also
I don't want to store it as plain text.
Do you know what is the usual practice in these cases?

[...]
In a nutshell, this is the point: you never use the plaintext form of
the password. As soon as it is entered, you convert it to a hash. You
store the hash, and if a user later enters a password and you need to
check it, you convert *it* to a hash and compare the hashes. Never,
ever, store or compare plain text passwords. Does that help?

-Peter

I think you have misunderstood me(mmm, I hope it sound polite enough in
english). An user should never enter the password again. I know how hashes
work, and they're useful when I can compare an entered password with an
hash value, but here I need that the user don't enter a password anymore
(after the first time).

The natural use of the program would be:
run the e-mail client for the first time
user enter his e-mail password
the client check for new mails
user close the client.

while 1:
user run the e-mail client
the client check for new mails WITHOUT ask for a password
user close the client

I hope I was clearer. I think Richard got the point, whit a "sad but true"
answer.

Ciao,
Riccardo
--
-=Riccardo Galli=-

_,e.
s~ ``
~@. ideralis Programs
.. ol
`**~ http://www.sideralis.net

[Aahz]

In article <pa****************************@riquito.matrix>,
Riccardo Attilio Galli <ri*****@riquito.matrix> wrote:

I think you have misunderstood me(mmm, I hope it sound polite enough in
english). An user should never enter the password again. I know how hashes
work, and they're useful when I can compare an entered password with an
hash value, but here I need that the user don't enter a password anymore
(after the first time).

The natural use of the program would be:
run the e-mail client for the first time
user enter his e-mail password
the client check for new mails
user close the client.

while 1:
user run the e-mail client
the client check for new mails WITHOUT ask for a password
user close the client

This is extremely difficult to do in a secure way. What you need to do
is encrypt the e-mail password before storage; each time the user starts
the e-mail application, zie needs to enter the local password. There are
other less secure options, all of which (with some partial exceptions)
equate to "no security" from the perspective of a security professional.
(E.g. relying on the OS to keep the data secure.)

Python does not make encryption available in its "batteries included"
philosophy because of the legal problems. M2Crypto is probably the
module most often used; see also
http://www.amk.ca/python/code/crypto.html
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan

[Leonardo Santagada]

Riccardo Attilio Galli wrote:

On Tue, 23 Sep 2003 09:28:49 -0400, Peter Hansen wrote:

I think you have misunderstood me(mmm, I hope it sound polite enough in
english). An user should never enter the password again. I know how hashes
work, and they're useful when I can compare an entered password with an
hash value, but here I need that the user don't enter a password anymore
(after the first time).

The natural use of the program would be:
run the e-mail client for the first time
user enter his e-mail password
the client check for new mails
user close the client.

while 1:
user run the e-mail client
the client check for new mails WITHOUT ask for a password
user close the client

I hope I was clearer. I think Richard got the point, whit a "sad but true"
answer.

Ciao,
Riccardo

I Really think he didn't understand you because hashing a password that
you will need again isn't possible. You need to store the password in a
crypt way, but I don't know how to generate the master password(the one
that is used by the crypto program to encrypt the pop or imap
passoword). I really don't understand a lot about encrypting something,
but sha1 and md5 are not reversible. If they were, then I would download
only the signature of a file and not the file. Now you need to know how
mozilla does it.

[Riccardo Attilio Galli]

On Tue, 23 Sep 2003 12:34:56 -0400, Aahz wrote:

This is extremely difficult to do in a secure way. What you need to do
is encrypt the e-mail password before storage; each time the user starts
the e-mail application, zie needs to enter the local password. There are
other less secure options, all of which (with some partial exceptions)
equate to "no security" from the perspective of a security professional.
(E.g. relying on the OS to keep the data secure.)

Python does not make encryption available in its "batteries included"
philosophy because of the legal problems. M2Crypto is probably the
module most often used; see also
http://www.amk.ca/python/code/crypto.html

ok, thank you all.

curiosity: what is "zie" intended to mean? It is maybe slang for he/she ?

Ciao,
Riccardo

--
-=Riccardo Galli=-

_,e.
s~ ``
~@. ideralis Programs
.. ol
`**~ http://www.sideralis.net

[Peter Hansen]

Riccardo Attilio Galli wrote:

curiosity: what is "zie" intended to mean? It is maybe slang for he/she ?

A Google search using "what is zie" turned up a page one above this one:

http://english.cla.umn.edu/GraduateP...ictionary.html

-Peter

[Aahz]

In article <pa****************************@riquito.matrix>,
Riccardo Attilio Galli <ri*****@riquito.matrix> wrote:

curiosity: what is "zie" intended to mean? It is maybe slang for he/she ?

It's a gender-neutral pronoun.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan

[G.A.]

On Tue, 23 Sep 2003 18:02:37 +0200, Riccardo Attilio Galli
<ri*****@riquito.matrix> wrote:

english). An user should never enter the password again. I know how hashes
work, and they're useful when I can compare an entered password with an
hash value, but here I need that the user don't enter a password anymore
(after the first time).

Better late than never: The only way to do this securely is to rely on the
operating system's security, and even that isn't always possible. I think
the NT/W2K model allows for encryption based on keys that only the specific
user can use (i.e. you have to actually be logged in as that user; I'm not
sure if the adminstrator can fake it). This won't work on 9X. On UNIX, a
close approximation is to just store the password in a file to which only
the user has read access, but obviously root will still have access.

Note that if the application supports multiple mail accounts for a single
user (as many do), then it becomes useful to have a single password for the
application, used to encrypt the various passwords for the different mail
accounts.

Gary

[Aahz]

In article <k5********************************@4ax.com>,
G.A. <ga*************@ziplink.stopallspam.net> wrote:

Better late than never: The only way to do this securely is to rely on
the operating system's security, and even that isn't always possible.
I think the NT/W2K model allows for encryption based on keys that
only the specific user can use (i.e. you have to actually be logged
in as that user; I'm not sure if the adminstrator can fake it). This
won't work on 9X. On UNIX, a close approximation is to just store
the password in a file to which only the user has read access, but
obviously root will still have access.
Exactly, and too many users don't properly secure their machines.
Note that if the application supports multiple mail accounts for a
single user (as many do), then it becomes useful to have a single
password for the application, used to encrypt the various passwords for
the different mail accounts.

That's better.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan

[Rudy Schockaert]

>>I think the NT/W2K model allows for encryption based on keys that

only the specific user can use (i.e. you have to actually be logged
in as that user; I'm not sure if the adminstrator can fake it).

This is the BIG security hole in NT/W2K. As an admininstrator you have
several ways to start a new process running in the security context of
someone else.

There are some approvements in W2K3 though. Still didn't find a way to
let Administrator impersonate as someone else.