Arch Linux

KylieGS

Member

Registered: 2018-02-19

Posts: 53

Secure Programming

I'm writting a little frontend for cryptsetup in Python. However this is the first project I've had that's required significant security. Is there anything in particular I have to do when handling passphrases? How do I stop it being exposed?

jaergenoth

Member

Registered: 2015-01-16

Posts: 85

Re: Secure Programming

I'm not completely sure what you mean, but if you just want to ask for passphrases and not echo them on screen, there is the getpass module that is part of the Python Standard Library.
Documentation: https://docs.python.org/3/library/getpass.html

Last edited by jaergenoth (2018-04-25 17:17:28)

KylieGS

Member

Registered: 2018-02-19

Posts: 53

Re: Secure Programming

Okay but any handling within the program can be consisered secure? I just don't want to find out that python variables are saved as plaintext somewhere accessable lol

eschwartz

Fellow

Registered: 2014-08-08

Posts: 4,097

Re: Secure Programming

The usual thing to remember here, is that anyone can look at command-line parameters using ps/top/htop. This typically comes into play when using bash variables, since everything is a commanline.

Unless you intend to shell out to some command from your python program, you should be fine. If you did do that though you should send passwords via a pipe to the command's stdin.

---

Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

ewaller

Administrator

From: Pasadena, CA

Registered: 2009-07-13

Posts: 19,791

Re: Secure Programming

They are not secure while they are in memory.   It is simple to attach a debugger and have complete visibility into a running program if you are logged in as the same user that the program is running as.
The best practice is to ensure they are used as fast as possible and then overwrite them in memory.  As to long term storage, that does not happen unless the program is written to do so.

Edit:  If you want to cure insomnia (or cause it if your job depends on security) read up on the standards used in the credit card industry as to security practices.  Look up PCI DSS

Last edited by ewaller (2018-04-25 18:59:51)

---

Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

frostschutz

Member

Registered: 2013-11-15

Posts: 1,418

Re: Secure Programming

No passwords in command line arguments, nor exported environment variables as those are more or less public under /proc/<PID>/{cmdline,environ}

That pretty much means you have to pipe the passphrase to cryptsetup's stdin, or create a file that is only readable by root.

So you have to read cryptsetup manpage NOTES ON PASSPHRASE PROCESSING because it treats stdin differently from files and files differently from actually typing a passphrase.

If possible, best to make it short (shorter than 512 bytes) and stick to ascii characters without newlines or otherwise special.

Of course even then anyone can strace your program and read but - same could be said about cryptsetup itself, so it does not really apply. Could as well argue anyone could use a $5 keylogger. Which is true but not within the means of a simple popup dialog to do anything about. Even if you were to add a secret salt, LUKS encrypted keyfiles, or whatever - all of which is more likely to lose someone their data if they don't know they have to backup these or need another backup/master passphrase in the partition's LUKS header.

Last edited by frostschutz (2018-04-25 20:14:00)

eschwartz

Fellow

Registered: 2014-08-08

Posts: 4,097

Re: Secure Programming

They are not secure while they are in memory.   It is simple to attach a debugger and have complete visibility into a running program if you are logged in as the same user that the program is running as.
The best practice is to ensure they are used as fast as possible and then overwrite them in memory.  As to long term storage, that does not happen unless the program is written to do so.

Edit:  If you want to cure insomnia (or cause it if your job depends on security) read up on the standards used in the credit card industry as to security practices.  Look up PCI DSS

Yes, but that's not really in scope of the issue, not much you can do if someone can log in as your own user and attach debuggers to every program you're running. The program's you're interacting with are just as vulnerable.

For the purpose of discussion, preventing other users from grabbing publicly available command-line options or env vars is probably sufficient and is what most other interactive software involved is probably doing.

---

Managing AUR repos The Right Way -- aurpublish (now a standalone tool)