I got smpt working using crates for my diy iot device.
I do not want to use human readable password in code so what is the best way to use encrypted password in lettre?
Passwords can't be encrypted by definition. If you send an "encrypted" password, this becomes the actual plaintext password. You could store it encrypted, but you would have to decrypt it before sending it over smtp, which requires the encryption key on your iot device and is thus semantically equivalent to storing it unencrypted.
2 Likes
This is a question that is very difficult to answer. You will find that there isn't necessarily a "right" answer. In general, however, do not store sensitive information within your application code. Retrieve it via environment variables, files, etc., but never store it within your code, regardless of whether it is encrypted or not. (I presume you mean "hashed" though -- a remote SMTP server would not be able to process an encrypted password.)
Edit: I actually don't think the SMTP protocol itself supports hashed or encrypted passwords without an external authentication provider.
1 Like
I am talking about startls and tls protocols.
There the password is encrypted during handshake but what I am looking is how to use only encrypted password in system. I have done that with bash and pgp but I would not like use bash scrips here.
What I think I need is to be able to decrypt the stored hash inside my application.
I'm confused by what your wanting to do. If your wanting to un-hash a hashed password, you can't. If your wanting to decrypt information, the cryptographic key has to be stored somewhere (not in your app!) so you would need to find it and decrypt it using that key. And whether you can do that depends on what you used to encrypt the password with.
TLS/startls is not used for encrypting data not in transit. It will only encrypt data that you transmit to the other server. To both you and the server the data appears unencrypted, but it will be encrypted to anyone who tries to listen on on the connection.
1 Like
If you want your IOT device to have the ability to send a password to the remote server, then it needs that ability. You can't simultaneously remove the password from it, and still have it sending it to the server.
If you store the password encrypted, you will need to also store a key to that encryption. And if you want the device to be able to run unattended, then it must store that key - and so, anyone with access to the device and access to the encrypted password will also have access to that key.
Long story short, if your application can decrypt the password to send it, so can anyone with access to the device. I would focus on the following instead for best security:
-
harden the device against attacks that gain access at all. For instance, make sure you are either manually applying security patches whenever any vulnerabilities appear, or in lieu of that, make sure you're at least automatically updating it with new versions of any packages or crates talking to the outside world fairly regularly.
-
see if you can give it an app-specific password or token - one that isn't your main password, but rather something only it uses. This way if it's compromised you only have to revoke its access
-
store the password on the device, separate from your codebase
This is something Ethindp suggested. If your device has an operating system, store it in a separate file, already stored on the device, and read it into your code. Or, an environmental variable would be equivalent here - both would avoid it being in your code and codebase itself.
If your device doesn't have an operating system, then that won't work. Maybe you could store it somewhere safe on your computer, and include it via
include_str!orenv!? These would still include the password in your built binary, and that isn't ideal, but if your software is the only thing running on the device then that's unavoidable.
Thanks for suucestions.
I understand that of course the key must be in my device stored somehow (f.ex. pgp private key) and if someone has full accees to system he can decrypt the cryped key. In such a situation I believe the system is lost anyhow because he can do what ever he wants. The key is not in the application code but in the system.
My target is to make it more difficult by having encrypetd password. At least so that some bots can't fint the password so easily.
System is going to be stand alone for long time and in place with difficult accessand should work as it is at least for half an year without any security updates. It is not so critical but I would like to protect the password of the email to reduce the need for updating.
What I am looking here is what is the best way to do decryption in rust for the encrypted stored password.
You seem to be confused about how TLS/startls works. A bot isn't going to be able to use your password at all. TLS will make sure of it. As long as you harden the device against outside intrusions and follow proper secure coding techniques and IOT device hardening techniques, your password will be safe. A spam bot isn't going to be capable of gaining access to your device let alone the sensitive information on it. Storing the password in an encrypted form is a bit of overkill if your doing it just to prevent that.
Also, if your software is the only software that the device runs (i.e. it acts as the OS) but the device has NVRAM support, you can store the password there.
I see that I am not very good to explain what I mean.
I understand that there is no broblem in TLS handshake, but I would not like to write the password in code as plain text.
What I am looking here is to use encrypted password that is decrypted by a function and can be used in code instead of plain text password.
Also the passphrase need to be hidden some way not to be visible in code.
I just want to do thios overkill because I may fail in hardening due new security faults appearing along system is in use and not able to update.
If I leave ports open for remote access it is even more vulnearable.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.