Date: Sun, 23 Sep 2007 15:27:35 +0200 (CEST) From: Christian Baer <christian.baer@uni-dortmund.de> To: freebsd-geom@freebsd.org Subject: Re: Pipes password from kdialog to geli attach Message-ID: <fd5pk7$2hh1$1@nermal.rz1.convenimus.net> References: <200709222256.17692.yarodin@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 22 Sep 2007 22:56:17 +0600 yarodin wrote:
> init:
> password=`kdialog --password "Enter the password"`
> echo $password|sha256|geli init -s 4096 -P -K - /dev/ad0s1e
Unless you are planning to create a lot of encrypted providers I don't
really see a point in actually writing a script for this. The providers
are usually initialized only once and then left like that for a really
long time. You'd do just as well to do this directly from the console or
in an Xterm.
> atach:
> password=`kdialog --password "Enter the password"`
> echo $password|sha256|geli attach -p -k - /dev/ad0s1e
Suggestion to add this:
echo "Checking ..."
fsck -fv -t ffs /dev/ad0s1e.eli
if [ $? -eq 0 ]; then
echo "Filesystem is ok, mounting it!"
mount /dev/ad0s1e.eli [/usr/secure]
if [ $? -eq 0 ]; then
echo "Mount succeeded!"
geli detach -l [/usr/secure]
else
echo "Mount failed, please check the filesystem manually!"
fi
else
echo "fsck failed! Please check the filesystem manually!"
fi
Encrypted filesystems don't have dirty tags and there is no way to find
out if the fs was unmounted cleanly or not. IMHO it's a good idea to run
fsck over the fs before every mount. It takes a while longer but you are
on the safe side. You can "spike" the command there a little to your
liking using the -p, -F, -B, -n or -y flags.
> Is it very unsecure? May be a better method exists?
Yes and no.
The script itself is fine. I don't see any security risks in the
implementation. Make sure your shell doesn't keep any variables in the
memory after finishing the script.
However, I *do* see a risk in the possibly weak passphrase.
Geli doesn't accept the Password piped to it, this only works with the
keyfile (as you have written there). A keyfile should normally consist of
random bits and because Geli assumes this, no salt is added.
Unfortunately, remembering a sequenz of random bits or even characters
isn't easy for a human and if this string is too short it is insecure by
design and also compromises sha. Since you seem to be the system's
administrator (root), you can work against this by issuing a strong
passphrase. Create a keyfile with random characters (that can be input
with the keyboard if need be) *and* think up a passphrase, preferably one
containing characters (small and capitals), numbers, punctuation and
symbols. Use known abreviations and ones you think up and even incorrect
spelling if you like. The passphrase could bei something like this: "76%
of the US of A's laW §s are old, outdated and completely useless(!); by
design!" No, I don't want to start a political discussion and BTW: this is
true for just about any country. :-) Note the capital 'W' in 'laW'.
Doesn't look like much but will completely change the hash. This is a
passphrase that will allmost certainly withstand a dictionary attack -
although is doesn't even contain all the mentioned examples for illuding
one, like strange spelling.
Save the keyfile somewhere safe (in several places), including a
USB-Stick. Then ask the user for both the passphrase and the keyfile and
somehow interweave them. This follows the principle "something you have
and something you know" as recommended by PHK. If You use a passphrase
like the example I just made up, you should be pretty safe.
If you have several providers you wish to attach, add a little something
to each keyfile-passphrase-combo before piping it to the hash. Maybe
something like this:
echo "SeCuRE01${password}sEcUre01" | sha256 | geli attach -p -k - /dev/ad0s1e
echo "SeCuRE02${password}sEcUre02" | sha256 | geli attach -p -k - /dev/ad1s1e
This way you can attach all providers with one passphrase and still stay
pretty secure.
Remember, a weak passphrase *always* compromises security and even salt
only mildly improves this. In this case you don't have any salt , so
everything falls and stands with the good passphrase and how safe you keep
your keyfile.
If you are using a good passphrase, you might want to add "-l 256" to the
init line, especially if the encrypted fs is pretty big. If you decide to
use a weak passphrase or just a password, because you don't need that much
security, don't add the -l option but instead "-e Blowfish". Blowfish is
much faster than AES, especially with these short keylengths. It's not as
secure as AES but still a lot harder to break open than a weak passphrase
or password.
I hope to have helped a little - without boring you too much.
Regards
Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fd5pk7$2hh1$1>