Is default home directory encryption with automount secure enough?
Clash Royale CLAN TAG#URR8PPP up vote
1
down vote
favorite
Default Ubuntu desktop installation offers an option to encrypt my /homeusing ecryptfs, and it auto-mounts the home every time I log in.
If my PC had stolen, couldn't the attacker have just substituted my /etc/shadow file and login as me, gaining access to my files? If yes, what is a use case for this encryption then?
security ecryptfs
asked Feb 20 at 13:07
Andriy Maletsky
1063
add a comment |Â
up vote
1
down vote
favorite
Default Ubuntu desktop installation offers an option to encrypt my /homeusing ecryptfs, and it auto-mounts the home every time I log in.
If my PC had stolen, couldn't the attacker have just substituted my /etc/shadow file and login as me, gaining access to my files? If yes, what is a use case for this encryption then?
security ecryptfs
asked Feb 20 at 13:07
Andriy Maletsky
1063
1
"If yes," No. But not encrypting/means they could add something to/to mail keyboard input (incl. your password) when you decrypt or decrypted your partition and access your data at a later time.
– Rinzwind
Feb 20 at 14:41
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
Default Ubuntu desktop installation offers an option to encrypt my /homeusing ecryptfs, and it auto-mounts the home every time I log in.
If my PC had stolen, couldn't the attacker have just substituted my /etc/shadow file and login as me, gaining access to my files? If yes, what is a use case for this encryption then?
security ecryptfs
asked Feb 20 at 13:07
Andriy Maletsky
1063
Default Ubuntu desktop installation offers an option to encrypt my /homeusing ecryptfs, and it auto-mounts the home every time I log in.
If my PC had stolen, couldn't the attacker have just substituted my /etc/shadow file and login as me, gaining access to my files? If yes, what is a use case for this encryption then?
security ecryptfs
security ecryptfs
asked Feb 20 at 13:07
Andriy Maletsky
1063
asked Feb 20 at 13:07
Andriy Maletsky
1063
asked Feb 20 at 13:07
Andriy Maletsky
1063
asked Feb 20 at 13:07
Andriy Maletsky
1063
asked Feb 20 at 13:07
Andriy Maletsky
1063
1063
1
"If yes," No. But not encrypting/means they could add something to/to mail keyboard input (incl. your password) when you decrypt or decrypted your partition and access your data at a later time.
– Rinzwind
Feb 20 at 14:41
add a comment |Â
1
"If yes," No. But not encrypting/means they could add something to/to mail keyboard input (incl. your password) when you decrypt or decrypted your partition and access your data at a later time.
– Rinzwind
Feb 20 at 14:41
1
1
"If yes," No. But not encrypting
/ means they could add something to / to mail keyboard input (incl. your password) when you decrypt or decrypted your partition and access your data at a later time.– Rinzwind
Feb 20 at 14:41
"If yes," No. But not encrypting
/ means they could add something to / to mail keyboard input (incl. your password) when you decrypt or decrypted your partition and access your data at a later time.– Rinzwind
Feb 20 at 14:41
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
You must provide your password during login to decrypt the home folder.
The password is not stored by Ubuntu in /etc/shadow. What you find there is only a hash of the password plus a short salt. When you log in, the password you entered gets hashed and then the hashes are compared.
It is not possible to retrieve the original password from that hash, except through trying all possible combinations until one matches.
So as long as you keep your password private and it is secure (long and complex) enough to withstand a brute-force (or dictionary) attack longer than the attention span of the attacker lasts, your encrypted home directory is safe.
To ecryptfs, it does not matter what hash is in the shadow file. It takes the password entered by the user at login and tries to decrypt the home folder with that. If it is the correct password, the decryption succeeds, if not, it will fail. By modifying the shadow file (or simply booting into a rescue mode root shell and resetting the account password), only the login password changes.
Encryption doesn't work by comparing hashes and deciding to let someone in or not, it works by doing lots and lots of maths using the password and the encrypted data on disk to get back the original data.
answered Feb 20 at 13:20
Byte Commander
59.7k26159268
I meant, attacker can take random string, hash it, and put the result in shadow instead of my hash. So then, ecryptfs uses my user password as key to my files, right?
– Andriy Maletsky
Feb 20 at 13:23
To ecryptfs, it does not matter what hash is in the shadow file. It takes the password entered by the user at login and tries to decrypt the home folder with that. If it is the correct password, the decryption succeeds, if not, it will fail. By modifying the shadow file (or simply booting into a rescue mode root shell and resetting the account password), only the login password changes. Encryption doesn't work by comparing hashes and deciding to let someone in or not, it works by doing lots and lots of maths using the password and the encrypted data on disk to get back the original data.
– Byte Commander
Feb 20 at 13:28
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
You must provide your password during login to decrypt the home folder.
The password is not stored by Ubuntu in /etc/shadow. What you find there is only a hash of the password plus a short salt. When you log in, the password you entered gets hashed and then the hashes are compared.
It is not possible to retrieve the original password from that hash, except through trying all possible combinations until one matches.
So as long as you keep your password private and it is secure (long and complex) enough to withstand a brute-force (or dictionary) attack longer than the attention span of the attacker lasts, your encrypted home directory is safe.
To ecryptfs, it does not matter what hash is in the shadow file. It takes the password entered by the user at login and tries to decrypt the home folder with that. If it is the correct password, the decryption succeeds, if not, it will fail. By modifying the shadow file (or simply booting into a rescue mode root shell and resetting the account password), only the login password changes.
Encryption doesn't work by comparing hashes and deciding to let someone in or not, it works by doing lots and lots of maths using the password and the encrypted data on disk to get back the original data.
answered Feb 20 at 13:20
Byte Commander
59.7k26159268
I meant, attacker can take random string, hash it, and put the result in shadow instead of my hash. So then, ecryptfs uses my user password as key to my files, right?
– Andriy Maletsky
Feb 20 at 13:23
To ecryptfs, it does not matter what hash is in the shadow file. It takes the password entered by the user at login and tries to decrypt the home folder with that. If it is the correct password, the decryption succeeds, if not, it will fail. By modifying the shadow file (or simply booting into a rescue mode root shell and resetting the account password), only the login password changes. Encryption doesn't work by comparing hashes and deciding to let someone in or not, it works by doing lots and lots of maths using the password and the encrypted data on disk to get back the original data.
– Byte Commander
Feb 20 at 13:28
add a comment |Â
up vote
1
down vote
You must provide your password during login to decrypt the home folder.
The password is not stored by Ubuntu in /etc/shadow. What you find there is only a hash of the password plus a short salt. When you log in, the password you entered gets hashed and then the hashes are compared.
It is not possible to retrieve the original password from that hash, except through trying all possible combinations until one matches.
So as long as you keep your password private and it is secure (long and complex) enough to withstand a brute-force (or dictionary) attack longer than the attention span of the attacker lasts, your encrypted home directory is safe.
To ecryptfs, it does not matter what hash is in the shadow file. It takes the password entered by the user at login and tries to decrypt the home folder with that. If it is the correct password, the decryption succeeds, if not, it will fail. By modifying the shadow file (or simply booting into a rescue mode root shell and resetting the account password), only the login password changes.
Encryption doesn't work by comparing hashes and deciding to let someone in or not, it works by doing lots and lots of maths using the password and the encrypted data on disk to get back the original data.
answered Feb 20 at 13:20
Byte Commander
59.7k26159268
I meant, attacker can take random string, hash it, and put the result in shadow instead of my hash. So then, ecryptfs uses my user password as key to my files, right?
– Andriy Maletsky
Feb 20 at 13:23
To ecryptfs, it does not matter what hash is in the shadow file. It takes the password entered by the user at login and tries to decrypt the home folder with that. If it is the correct password, the decryption succeeds, if not, it will fail. By modifying the shadow file (or simply booting into a rescue mode root shell and resetting the account password), only the login password changes. Encryption doesn't work by comparing hashes and deciding to let someone in or not, it works by doing lots and lots of maths using the password and the encrypted data on disk to get back the original data.
– Byte Commander
Feb 20 at 13:28
add a comment |Â
up vote
1
down vote
up vote
1
down vote
You must provide your password during login to decrypt the home folder.
The password is not stored by Ubuntu in /etc/shadow. What you find there is only a hash of the password plus a short salt. When you log in, the password you entered gets hashed and then the hashes are compared.
It is not possible to retrieve the original password from that hash, except through trying all possible combinations until one matches.
So as long as you keep your password private and it is secure (long and complex) enough to withstand a brute-force (or dictionary) attack longer than the attention span of the attacker lasts, your encrypted home directory is safe.
To ecryptfs, it does not matter what hash is in the shadow file. It takes the password entered by the user at login and tries to decrypt the home folder with that. If it is the correct password, the decryption succeeds, if not, it will fail. By modifying the shadow file (or simply booting into a rescue mode root shell and resetting the account password), only the login password changes.
Encryption doesn't work by comparing hashes and deciding to let someone in or not, it works by doing lots and lots of maths using the password and the encrypted data on disk to get back the original data.
answered Feb 20 at 13:20
Byte Commander
59.7k26159268
You must provide your password during login to decrypt the home folder.
The password is not stored by Ubuntu in /etc/shadow. What you find there is only a hash of the password plus a short salt. When you log in, the password you entered gets hashed and then the hashes are compared.
It is not possible to retrieve the original password from that hash, except through trying all possible combinations until one matches.
So as long as you keep your password private and it is secure (long and complex) enough to withstand a brute-force (or dictionary) attack longer than the attention span of the attacker lasts, your encrypted home directory is safe.
To ecryptfs, it does not matter what hash is in the shadow file. It takes the password entered by the user at login and tries to decrypt the home folder with that. If it is the correct password, the decryption succeeds, if not, it will fail. By modifying the shadow file (or simply booting into a rescue mode root shell and resetting the account password), only the login password changes.
Encryption doesn't work by comparing hashes and deciding to let someone in or not, it works by doing lots and lots of maths using the password and the encrypted data on disk to get back the original data.
answered Feb 20 at 13:20
Byte Commander
59.7k26159268
edited Feb 20 at 13:28
answered Feb 20 at 13:20
Byte Commander
59.7k26159268
answered Feb 20 at 13:20
Byte Commander
59.7k26159268
answered Feb 20 at 13:20
Byte Commander
59.7k26159268
59.7k26159268
I meant, attacker can take random string, hash it, and put the result in shadow instead of my hash. So then, ecryptfs uses my user password as key to my files, right?
– Andriy Maletsky
Feb 20 at 13:23
To ecryptfs, it does not matter what hash is in the shadow file. It takes the password entered by the user at login and tries to decrypt the home folder with that. If it is the correct password, the decryption succeeds, if not, it will fail. By modifying the shadow file (or simply booting into a rescue mode root shell and resetting the account password), only the login password changes. Encryption doesn't work by comparing hashes and deciding to let someone in or not, it works by doing lots and lots of maths using the password and the encrypted data on disk to get back the original data.
– Byte Commander
Feb 20 at 13:28
add a comment |Â
I meant, attacker can take random string, hash it, and put the result in shadow instead of my hash. So then, ecryptfs uses my user password as key to my files, right?
– Andriy Maletsky
Feb 20 at 13:23
To ecryptfs, it does not matter what hash is in the shadow file. It takes the password entered by the user at login and tries to decrypt the home folder with that. If it is the correct password, the decryption succeeds, if not, it will fail. By modifying the shadow file (or simply booting into a rescue mode root shell and resetting the account password), only the login password changes. Encryption doesn't work by comparing hashes and deciding to let someone in or not, it works by doing lots and lots of maths using the password and the encrypted data on disk to get back the original data.
– Byte Commander
Feb 20 at 13:28
I meant, attacker can take random string, hash it, and put the result in shadow instead of my hash. So then, ecryptfs uses my user password as key to my files, right?
– Andriy Maletsky
Feb 20 at 13:23
I meant, attacker can take random string, hash it, and put the result in shadow instead of my hash. So then, ecryptfs uses my user password as key to my files, right?
– Andriy Maletsky
Feb 20 at 13:23
To ecryptfs, it does not matter what hash is in the shadow file. It takes the password entered by the user at login and tries to decrypt the home folder with that. If it is the correct password, the decryption succeeds, if not, it will fail. By modifying the shadow file (or simply booting into a rescue mode root shell and resetting the account password), only the login password changes. Encryption doesn't work by comparing hashes and deciding to let someone in or not, it works by doing lots and lots of maths using the password and the encrypted data on disk to get back the original data.
– Byte Commander
Feb 20 at 13:28
To ecryptfs, it does not matter what hash is in the shadow file. It takes the password entered by the user at login and tries to decrypt the home folder with that. If it is the correct password, the decryption succeeds, if not, it will fail. By modifying the shadow file (or simply booting into a rescue mode root shell and resetting the account password), only the login password changes. Encryption doesn't work by comparing hashes and deciding to let someone in or not, it works by doing lots and lots of maths using the password and the encrypted data on disk to get back the original data.
– Byte Commander
Feb 20 at 13:28
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1008030%2fis-default-home-directory-encryption-with-automount-secure-enough%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
"If yes," No. But not encrypting
/means they could add something to/to mail keyboard input (incl. your password) when you decrypt or decrypted your partition and access your data at a later time.– Rinzwind
Feb 20 at 14:41