asked on
Python Password Encryption
Hello, Experts,
I am new to the encryption world. I have some python experience under my belt but not much when it comes to encrypting passwords. I have compiled a python script that is very simple. It queries a directory > grabs a specific type of file > starts a FTP transmission > ends.
Currently, in testing, my python script has the URL, username, password in cleartext. For obvious reasons, I want to move away from that. What is the best practice to encrypt my data?
Assumptions:
It would make sense for me since this script will be deployed globally to encrypt password once, store in some sort of file, then reference later in the script.
I am looking for some pointers, examples, and best practices.
I am new to the encryption world. I have some python experience under my belt but not much when it comes to encrypting passwords. I have compiled a python script that is very simple. It queries a directory > grabs a specific type of file > starts a FTP transmission > ends.
Currently, in testing, my python script has the URL, username, password in cleartext. For obvious reasons, I want to move away from that. What is the best practice to encrypt my data?
Assumptions:
- Script will be downloaded from an FTP host to various machines
- The script will be placed in a hidden dir
- Service will run to kick off-script during an interval
It would make sense for me since this script will be deployed globally to encrypt password once, store in some sort of file, then reference later in the script.
I am looking for some pointers, examples, and best practices.
#import libraries
import os
import pysftp
# query for file to ftp
alr_file = '/Users/path/to/file/to_ftp'
ftpALR = []
def findFile():
for item in os.listdir(alr_file):
if item.endswith('.mdb'):
ftpALR.append(alr_file + '/' + item)
# ftp transmission function
def ftpTransmit():
# list ftp dir
cnopts = pysftp.CnOpts()
cnopts.hostkeys = None
with pysftp.Connection(host='ftp.acme.com',
username='cloudUser',
password='NOT_A_REAL_PWD',
port=22,
cnopts=cnopts) as sftp:
length = len(ftpALR)
for i in range(length):
sftp.put(ftpALR[i])
findFile()
ftpTransmit()
EncryptionFTPPython
Last Comment
noci
ASKER
Hi @noci,
Thanks for your reply.
I am using the SFTP protocol. I am having difficulty using cert authentication - hence why I need to use the user name and password to auth when the script runs.
The idea is to have the password variable containing an encrypted value and importing the other python script that does encrypting and decrypting so that when the pwd field is sent out for the SFTP request the server can read the decrypted string.
I guess again, being new to all this, its fairly vague to me what best practice should be. Hence me reaching out for help/advice.
Thanks for your reply.
I am using the SFTP protocol. I am having difficulty using cert authentication - hence why I need to use the user name and password to auth when the script runs.
The idea is to have the password variable containing an encrypted value and importing the other python script that does encrypting and decrypting so that when the pwd field is sent out for the SFTP request the server can read the decrypted string.
I guess again, being new to all this, its fairly vague to me what best practice should be. Hence me reaching out for help/advice.
A password can never be hidden for long. People may run the program using a debugger or tracing tools and just see it in front of them.
With certificate you can create pairs / user or even multiple pairs per user. You hand the private key part with the program and keep the public key in the authorized list on the server. Then passwords are not needed. If the account is removed either the one offending public key can be removed or all keys can be removed.
Note to future reader, added after comment from David below: In this case the central organisation can issue the private key.
HARD REQUIREMENTS: THE KEYPAIR ABOVE IS USED FOR EXACTLY ONE CUSTOMER, THE CUSTOMER DOES NOT USE THE PRIVATE KEY FOR ANYTHING ELSE.
Anyway you have total control without the need to hide anything. Hiding data is security by obscurity which never holds.
With certificate you can create pairs / user or even multiple pairs per user. You hand the private key part with the program and keep the public key in the authorized list on the server. Then passwords are not needed. If the account is removed either the one offending public key can be removed or all keys can be removed.
Note to future reader, added after comment from David below: In this case the central organisation can issue the private key.
HARD REQUIREMENTS: THE KEYPAIR ABOVE IS USED FOR EXACTLY ONE CUSTOMER, THE CUSTOMER DOES NOT USE THE PRIVATE KEY FOR ANYTHING ELSE.
Anyway you have total control without the need to hide anything. Hiding data is security by obscurity which never holds.
You hand the private key part with the program and keep the public key in the authorized list on the server
isn't it the otherway around, you keep the private and give out the public?
isn't it the otherway around, you keep the private and give out the public?
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
@david: yes you are normally right... A client should create a keypair and the central organisation should only receive the PUBLIC key.
With SSH the usage of keys is user centric, the client has the private key, the server to be managed need the public key......
so any "Centralized" solution needs to work the other way around . (NX from nomachine has the same "problem"...).
That requires education of all customers to access the central organisation. And probably a lot of frustration.
In this case the central organisations is the trusted part anyway (as far as i can get from the Q).
So imho the risk is acceptable. (IF THE KEYPAIR is only used for THIS connection).
With SSH the usage of keys is user centric, the client has the private key, the server to be managed need the public key......
so any "Centralized" solution needs to work the other way around . (NX from nomachine has the same "problem"...).
That requires education of all customers to access the central organisation. And probably a lot of frustration.
In this case the central organisations is the trusted part anyway (as far as i can get from the Q).
So imho the risk is acceptable. (IF THE KEYPAIR is only used for THIS connection).
Try SCP / SSH in stead.
When using ssh/scp then you can also use certificates instead of password greatly simplifying what needs to be scripted.