Solved Security: How safe is a password prompt versus a key

R

Relictrix

Hi,

Preparing an external disk with geli and a possible ZFS native encrypted dataset, I wonder how safe is a password prompt vs using a key.

An encrypted disk with GELI and a native encrypted ZFS can be setup with a password prompt or a key file. I would think that password prompts which are entered via the keyboard or the clipboard from a password manager, are vulnerable for keyloggers. When a keyfile is used I suppose that file can be found and is vulnerable too.

- I am not an expert but what is the best choice?
- As above explained examples have no way to read it from smartcards or hardware token directly, how safe are they?

Best Regards,

R
 
Relictrix said:
Preparing an external disk with geli and a possible ZFS native encrypted dataset
Click to expand...
Well. Don't store the key on a USB stick and keep the external disk and USB stick together. Or put a sticker on it with the password.

Relictrix said:
I wonder how safe is a password prompt vs using a key.
Click to expand...
Ideally you want to do both. Something you have (the key) and something you know (the password).

Relictrix said:
An encrypted disk with GELI and a native encrypted ZFS can be setup with a password prompt or a key file.
Click to expand...
Password prompt and/or key file. You can set this up requiring both.

Relictrix said:
I would think that password prompts which are entered via the keyboard or the clipboard from a password manager, are vulnerable for keyloggers. When a keyfile is used I suppose that file can be found and is vulnerable too.
Click to expand...
Sure. That's why you do both. The key is useless without the password and the password is useless without the key.
 
Hi,

In reaction to your answer, SirDice. Just thinking out loud.

  • Can a prompt be trusted, I mean suppose a keylogger or some bot is gathering input from the keyboard?
  • Suppose the password consist of a memorized passphrase + a OTP yubikey (push on the button). If I understand it correctly the passphrase comes from the keyboard and the Yubikey too, because the Yubikey is in fact also considered as a keyboard. So both can be captured by some bot, or keylogger or malware whatever. So is it safe or not? I would think not, but am I right?
  • Suppose a tool captures everything I type on a daily basis, then it would be quiet easy to capture the passwords. Because memorized passwords are mostly too short compared to generate complex passwords. So I use a generated password and during the day I type sentences and words separated by spaces. So if a tool would capture everything I type, the only sequencing, long word without any space will be the password of my disk or a password for a certain account. You see what I mean, the only long, 40 or 50 sequencing characters (lower, upper, special sign and numers) in a row will probably be just the password.
  • What I am trying to find is. If I have a disk and it's encrypted with GELI or if there is only 1 dataset and it's native encrypted with ZFS with a passphrase. When somebody steals that disk , I think I am fine. Again I am not the expert but I think it's not possible to break it, at least that should be the goal :). But if I am working on that disk , on a windows HOST running a VM with Freebsd or even directly on a FreeBSD and the PC is compromised and I don't know it, is it then safe to open the disk? We might all think it's super safe but maybe hot storage is at the moment that we insert the password not safe.
  • When comparing passphrase or prompts or keyfiles with FIDO2 for example, then I think that capturing information when logging in with FIDO2 is less vulnerable.
Thanks in advance,
R
 
Relictrix said:
  • Can a prompt be trusted, I mean suppose a keylogger or some bot is gathering input from the keyboard?
Click to expand...
a prompt, whatever software you have downloaded, your network, and your hardware cannot be trusted, but this isn't as meaningful as it sounds. there's always a chance something is compromised. if that bothers you, i would try this on a machine that you have some amount of confidence in, rather than one you're unsure of. if the information you're encrypting is really that valuable, then it's just one extra step.
 
Relictrix said:
Suppose the password consist of a memorized passphrase + a OTP yubikey (push on the button). If I understand it correctly the passphrase comes from the keyboard and the Yubikey too, because the Yubikey is in fact also considered as a keyboard. So both can be captured by some bot, or keylogger or malware whatever. So is it safe or not? I would think not, but am I right?
Click to expand...
One-time password:
A one-time password (OTP), also known as a one-time PIN, one-time authorization code (OTAC) or dynamic password, is a password that is valid for only one login session or transaction, on a computer system or other digital device.
Click to expand...
So it doesn't matter if it gets captured or not, you can't reuse that one-time password.
 
Relictrix, use a 4-5 word passphrase (not a password). Do not forget it but do not write it down or save it anywhere.

External keys introduce an addition layer of potential failure.
 
Relictrix said:
  • ... on a windows HOST running a VM with Freebsd ...
Click to expand...

just don't do that. I mean, if you value the secrecy of your data do not use a closed source operating system that has access to all memory and sends data to skynet. If you tend to run a security-paranoid sane environment as I do with some of my clients, an intrusion detection system is necessary on all systems that access the disks.
While encrypted zfs datasets are nice if you just intend to use a subset of your valuable data, let me speak out a warning: I have had some cases where data was not readable after an upgrade. I am currently investigating this again (happened ~2020 and just a few days ago again). And key material like truststores, ssh/gpg keys etc. should be encrypted anyway, no matter if the underlying filesystem is encrypted or not.

You may also consider something like an Ironkey from Kingston, works great.
 
rootbert said:
just don't do that. I mean, if you value the secrecy of your data do not use a closed source operating system that has access to all memory and sends data to skynet. If you tend to run a security-paranoid sane environment as I do with some of my clients, an intrusion detection system is necessary on all systems that access the disks.
While encrypted zfs datasets are nice if you just intend to use a subset of your valuable data, let me speak out a warning: I have had some cases where data was not readable after an upgrade. I am currently investigating this again (happened ~2020 and just a few days ago again). And key material like truststores, ssh/gpg keys etc. should be encrypted anyway, no matter if the underlying filesystem is encrypted or not.

You may also consider something like an Ironkey from Kingston, works great.
Click to expand...
- Yes probably you are right, I might need to be more strict and only like you say: use a open source OS.
- Interesting to know these issues with encrypted zfs datasets! That's something I definitely don't want to experience :).
 
tux2bsd said:
Relictrix, use a 4-5 word passphrase (not a password). Do not forget it but do not write it down or save it anywhere.

External keys introduce an addition layer of potential failure.
Click to expand...
Hi tux2bsd,
I think it's not safe to use words, with dictionary attacks they can be found very easily. Some password tools are specially build to crack password built with words.
Best Regards
 
Two general comments about security: First, consider the value of your data (how motivated are attackers to get it), and possible attack vectors. Second, all security is a compromise, between statistically better protection of your data, versus loss of convenience, cost of managing, and sense of false security making things actually worse.

Relictrix said:
I would think that password prompts which are entered via the keyboard or the clipboard from a password manager, are vulnerable for keyloggers.
Click to expand...
If all your keystrokes (whether typed at a keyboard, or cut-and-pasted from a password manager) are being recorded by a keylogger, you have completely lost the war. At this point, your geli password is just one small battle. One of the things that protects you somewhat is that installing a keylogger and analyzing all keystrokes is very expensive for an attacker, and only likely to happen if you have high value data, or are the target of well-equipped hackers (big criminal organizations, nation-states, or intelligence agencies). Therefore, I conclude that you have organized your affairs such that the probability of a key logger running is very low.

All this leaves the question of where your password is stored. A yellow sticker on the edge of your monitor can be very secure, or very insecure, depending on the physical location of your monitor. Your brain can be very secure or insecure, depending on whether you like to pick bad passwords, talk to yourself while sitting in coffee shops, and what your pain tolerance during torture is (that's called a rubber hose attack, look it up on the web).

When a keyfile is used I suppose that file can be found and is vulnerable too.
Click to expand...
That depends on how the keyfile is stored. Here is a very secure example: The only copy of the keyfile exists on a USB stick, and that USB stick is nearly always in your pocket (for example with the keys to your house and your car). You only plug it in for a moment after booting, when you need to unlock the geli partition. That is very secure. Opposite example: The key file is unprotected, stored on a FAT partition of the same disk that holds your geli partition: Exceedingly insecure if someone gets logged in as root, or takes physical possession of the disk drive.

As above explained examples have no way to read it from smartcards or hardware token directly, how safe are they?
Click to expand...
If implemented well, they are often the safest option, because they rely on something you have (the physical key), something you know (the password), and some characteristic (like the fingerprint), or at least two of the three. But implementing this is a lot of work, and I don't know a simple recipe for doing it in the open source ecosystem.

I am not an expert but what is the best choice?
Click to expand...
It depends on your requirements, your use case, and your skills and resources.
 
Interesting post ralphbsz !

ralphbsz said:
If implemented well, they are often the safest option, because they rely on something you have (the physical key), something you know (the password), and some characteristic (like the fingerprint), or at least two of the three. But implementing this is a lot of work, and I don't know a simple recipe for doing it in the open source ecosystem.
Click to expand...
Indeed, I think so too , will not be easy. Room to improve.
 
rootbert said:
While encrypted zfs datasets are nice if you just intend to use a subset of your valuable data, let me speak out a warning: I have had some cases where data was not readable after an upgrade. I am currently investigating this again (happened ~2020 and just a few days ago again).
Click to expand...
I'd like to start using encrypted ZFS datasets, but your warning scares me a bit. Could you provide more details about unreadability your data after upgrade? Was it a FreeBSD upgrade or zpool upgrade? FreeBSD version, etc.
 
You must log in or register to reply here.
Back
Top