Re: [dev] [PATCH] [ubase] Simplify login
On Wed, 4 Jun 2014 00:15:58 +0200 Alexander Huemer alexander.hue...@xx.vu wrote: You think so? That's not at all what I personally associate with this feature. Can you elaborate? Many people don't understand how hashing-functions work. The shadow-file might suggest knowing the hash inherently unveils the password in some magic way. In reality, the incorporation of the shadow-file was motivated to make brute-force-attacks slower and less effective, but they are still possible. Thus, the shadow file locks things up a bit more, brings some more complexity, but this doesn't mean /etc/passwd is insecure. If you use strong passwords, you don't need the shadow-file. If you have a weak password, the shadow-file on the other hand just delays the eventual breach. Looking at it from the programmer's side: Implementing /etc/shadow brings more complexity to the program. Avoiding complexity is one goal to set, thus avoiding /etc/shadow is a good way to simplify things. As Dimitris said before: If you are serious about breaking into a computer, the security brought by login is laughable and easy to circumvent. Cheers FRIGN -- FRIGN d...@frign.de
Re: [dev] [PATCH] [ubase] Simplify login
On Wed, Jun 04, 2014 at 12:44:01PM +0200, FRIGN wrote: On Wed, 4 Jun 2014 00:15:58 +0200 Alexander Huemer alexander.hue...@xx.vu wrote: You think so? That's not at all what I personally associate with this feature. Can you elaborate? Many people don't understand how hashing-functions work. Obviously true. The shadow-file might suggest knowing the hash inherently unveils the password in some magic way. This _might_ suggest that, but I'd say that's far fetched. In reality, the incorporation of the shadow-file was motivated to make brute-force-attacks slower and less effective, but they are still possible. I don't think that was the sole motivation, just one of them. Thus, the shadow file locks things up a bit more, brings some more complexity It adds some complexity, but quite moderately. You want to have those hashing algos on your system anyway. but this doesn't mean /etc/passwd is insecure. That's true, but not the point here. If you use strong passwords, you don't need the shadow-file. If you have a weak password, the shadow-file on the other hand just delays the eventual breach. Looking at it from the programmer's side: Implementing /etc/shadow brings more complexity to the program. Avoiding complexity is one goal to set, thus avoiding /etc/shadow is a good way to simplify things. As Dimitris said before: If you are serious about breaking into a computer, the security brought by login is laughable and easy to circumvent. Obviously true. Physical access to a machine that does not store the data encrypted is a sure win for the attacker. LG, -Alex
Re: [dev] [PATCH] [ubase] Simplify login
On Wed, Jun 04, 2014 at 12:44:01PM +0200, FRIGN wrote: Looking at it from the programmer's side: Implementing /etc/shadow brings more complexity to the program. Avoiding complexity is one goal to set, thus avoiding /etc/shadow is a good way to simplify things. The implementation turned out to be simple enough. Factoring out the routines in util/ should make the code more readable.
Re: [dev] [PATCH] [ubase] Simplify login
On Wed, 4 Jun 2014 12:55:39 +0100 Dimitris Papastamos s...@2f30.org wrote: The implementation turned out to be simple enough. Factoring out the routines in util/ should make the code more readable. The similarities between su and login are a good reason to do the handling in one place. -- FRIGN d...@frign.de
Re: [dev] [PATCH] [ubase] Simplify login
On Wed, Jun 04, 2014 at 02:21:51PM +0200, FRIGN wrote: On Wed, 4 Jun 2014 12:55:39 +0100 Dimitris Papastamos s...@2f30.org wrote: The implementation turned out to be simple enough. Factoring out the routines in util/ should make the code more readable. The similarities between su and login are a good reason to do the handling in one place. Yeah exactly.
Re: [dev] [PATCH] [ubase] Simplify login
Thus, the shadow file locks things up a bit more, brings some more complexity, but this doesn't mean /etc/passwd is insecure. If you use strong passwords, you don't need the shadow-file. If you have a weak password, the shadow-file on the other hand just delays the eventual breach. The problem arises when you have a system with hundred of users. You have to ensure that all the users have a strong password (some of them without any basic knowledge about computers or security), so the only way is modifying passwd program to force secure passwords, so at the end you add complexity in another part of the system. -- Roberto E. Vargas Caballero
Re: [dev] [PATCH] [ubase] Simplify login
On Wed, 4 Jun 2014 17:14:19 +0200 Roberto E. Vargas Caballero k...@shike2.com wrote: The problem arises when you have a system with hundred of users. You have to ensure that all the users have a strong password (some of them without any basic knowledge about computers or security), so the only way is modifying passwd program to force secure passwords, so at the end you add complexity in another part of the system. I wouldn't mind a complex passwd, given it's rarely called in comparison to the entire login-routine. In which way is a /etc/passwd with hundreds of users less secure than a smaller one? Do many hashes in one place magically reduce the overall security? Remember: Both shadow-files and normal passwd-files are weak when the password is weak. Cheers FRIGN -- FRIGN d...@frign.de
Re: [dev] [PATCH] [ubase] Simplify login
On Wed, 4 Jun 2014 17:28:02 +0200 Roberto E. Vargas Caballero k...@shike2.com wrote: It is not about the security of /etc/passwd, it is about you cannot ensure that hundred of users will use strong password, because you don't select theirs passwords, so at the end the security of your system depend of the password choosen by your users. Well, who cares if one of them uses a weak password? The worst thing that could happen is that this user is cracked and all his data lost. No other users would be affected and in most cases not the system in general. If single users have higher access to valuable services, it is nonetheless mandatory to make sure their passwords are safe. However, who would let a n00b manage important stuff? Cheers FRIGN -- FRIGN d...@frign.de
Re: [dev] [PATCH] [ubase] Simplify login
Well, who cares if one of them uses a weak password? WOW!, so, for you, it isn't important if you have a non legitimate user, that can use your machine as base for attacking another machines. And, of course, it isn't important if you have an atacker in your system with all the time of the world to can search vulnerabilities in your system. The first step of any atack is always get some non privileged account and later try to get root privilegies from it. And when you have a big number of users, it means that the atacker is going to have more of one password of users, so when you detect the intrussion the only thing you can do is change the password of all the users... There is a very good book that shows the problem of users with weak password, The cuckoo's Egg. It is a novel based in the experience of Clifford Stoll hunting a hacker at the end of 80's, but a lot of things can be applied today (there is also a technical paper, but the novel is really good and less boring ;)). Regards, -- Roberto E. Vargas Caballero
Re: [dev] [PATCH] [ubase] Simplify login
Heyho, FRIGN wrote: In which way is a /etc/passwd with hundreds of users less secure than a smaller one? Do many hashes in one place magically reduce the overall security? Not precisely. But if you have a large amount of users, the probability that one of them chose a weak common password is higher than for a small set of users. Say you want to check your u users against the n most common passwords. Let p be the probability for a user choosing one of the n passwords. Then you have at least one user with a weak password with a probability of: 1 - (1-p)^u So with u growing linearly, you have linearly more work to check all users against the n passwords (assume a unique salt value per user), but exponentially growing probability of finding a match. So for systems with large user counts it is easier to find a user with a weak password, but it does not influence your user account at all if you use a strong (strong = password is not one of the n most common ones) password. --Markus
Re: [dev] [PATCH] [ubase] Simplify login
On Wed, 4 Jun 2014 17:46:40 +0200 Markus Teich markus.te...@stusta.mhn.de wrote: So for systems with large user counts it is easier to find a user with a weak password, but it does not influence your user account at all if you use a strong (strong = password is not one of the n most common ones) password. And in the end you still check against all hashes ;). Nice approach with the probability-theory! Cheers FRIGN -- FRIGN d...@frign.de
Re: [dev] [PATCH] [ubase] Simplify login
On Wed, 4 Jun 2014 17:40:39 +0200 Roberto E. Vargas Caballero k...@shike2.com wrote: WOW!, so, for you, it isn't important if you have a non legitimate user, that can use your machine as base for attacking another machines. And, of course, it isn't important if you have an atacker in your system with all the time of the world to can search vulnerabilities in your system. Before he gets in, he still has to run a brute-force/dictionary-att. on all users. He wouldn't have much time if the admins have done their jobs. The first step of any atack is always get some non privileged account and later try to get root privilegies from it. Yep. And when you have a big number of users, it means that the atacker is going to have more of one password of users, so when you detect the intrussion the only thing you can do is change the password of all the users... No? How would that happen? If an attacker ran an attack and detected a password of one user, this wouldn't magically reveal the other passwords to him. If an intrusion for one user has been detected (with the low probability that the cracker hasn't already been detected before), you just make sure this user is deactivated and can't do any more harm more to himself than to the system. Moreover, with less and less suid-programs in the base, root-exploits become more and more unlikely and attacks nowadays are more directed at system-services from the outside. There is a very good book that shows the problem of users with weak password, The cuckoo's Egg. It is a novel based in the experience of Clifford Stoll hunting a hacker at the end of 80's, but a lot of things can be applied today (there is also a technical paper, but the novel is really good and less boring ;)). Cool, I'll check it out! Thanks for the recommendation! Cheers FRIGN -- FRIGN d...@frign.de
Re: [dev] [PATCH] [ubase] Simplify login
Quoth FRIGN: Before he gets in, he still has to run a brute-force/dictionary-att. on all users. He wouldn't have much time if the admins have done their jobs. Well no. Think about sysadmins who have to allow users to run crappy PHP code on a shared server (so glad I'm not one of those people at the moment). An attacker can execute commands as a web user, probably far easier than brute-forcing an initial login. If they can then just copy a world readable /etc/passwd, they can do all the hash cracking offline. Which isn't possible if there's a /etc/shadow file that's unreadable to a web user. Unless I'm missing something, that's the value of the shadow system in a modern environment, when coupled with the problem that you can't necessarily trust that all users have very strong passwords. Plus your idea of what constitutes a 'strong' password is probably quite a few years out of date. I read a fun article on Ars Technica about about how brute-force cracking is done nowadays; it's pretty smart! http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/ Moreover, with less and less suid-programs in the base, root-exploits become more and more unlikely and attacks nowadays are more directed at system-services from the outside. That certainly seems to be true. After all, why get root on paypal's servers; the money is in any account that can access their database, which (probably at some levels of remove) is just an 'unprivelaged' web user. Nick
Re: [dev] [PATCH] [ubase] Simplify login
On Wed, 4 Jun 2014 12:22:04 -0400 Nick suckless-...@njw.me.uk wrote: Well no. Think about sysadmins who have to allow users to run crappy PHP code on a shared server (so glad I'm not one of those people at the moment). An attacker can execute commands as a web user, probably far easier than brute-forcing an initial login. If they can then just copy a world readable /etc/passwd, they can do all the hash cracking offline. Which isn't possible if there's a /etc/shadow file that's unreadable to a web user. Unless I'm missing something, that's the value of the shadow system in a modern environment, when coupled with the problem that you can't necessarily trust that all users have very strong passwords. Plus your idea of what constitutes a 'strong' password is probably quite a few years out of date. I read a fun article on Ars Technica about about how brute-force cracking is done nowadays; it's pretty smart! http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/ Okay, you convinced me. A shadow-file definitely makes sense in a multi-user-system and hashes of even strong passwords aren't as safe as I thought. Running a dictionary-attack on the hashes directly is a smart move I read about, but honestly didn't remember as well as I should have. That certainly seems to be true. After all, why get root on paypal's servers; the money is in any account that can access their database, which (probably at some levels of remove) is just an 'unprivelaged' web user. Yep, that's true! In many cases comfort is the biggest vulnerability in modern web-applications and services. -- FRIGN d...@frign.de
Re: [dev] [PATCH] [ubase] Simplify login
Before he gets in, he still has to run a brute-force/dictionary-att. on all users. He wouldn't have much time if the admins have done their jobs. Well no. Think about sysadmins who have to allow users to run crappy PHP code on a shared server (so glad I'm not one of those people at the moment). An attacker can execute commands as a web user, probably far easier than brute-forcing an initial login. If they can then just copy a world readable /etc/passwd, they can do all the hash cracking offline. Which isn't possible if there's a /etc/shadow This reminds me this document [1], which explains how some guys defeated apache.org server long, long time ago. Very good. Regards, [1] http://archives.neohapsis.com/archives/php/2000-05/att-0030/51-how_defaced_apache_org.txt -- Roberto E. Vargas Caballero
Re: [dev] [PATCH] [ubase] Simplify login
On Mon, Jun 02, 2014 at 06:41:45PM +0200, FRIGN wrote: Well, I prefer /etc/passwd, given it gives a false feeling of security using the shadow-file. In reality, it's a solution for a very unimportant issue. If your password is strong, having the hashes won't help any attacker. On the other hand, having a weak password, the shadow-file doesn't save you from a breach. Well, it won't save you, but delay it significantly! Testing a password with login takes 5 seconds, testing a password with the hash at hand takes less than a microsecond. But I concur this issue is pretty unimportant. Most security breaches these days occur due to faulty software allowing arbitrary code execution from network input. Or some fault/feature in the operating system allowing circumvention of the login prompt. (If you give me physical access to a Linux box, I'll get access to it.) So knowing a password isn't necessary any more. Cheers FRIGN Ciao, Markus
Re: [dev] [PATCH] [ubase] Simplify login
On Tue, 3 Jun 2014 21:16:01 +0200 Markus Wichmann nullp...@gmx.net wrote: Well, it won't save you, but delay it significantly! Testing a password with login takes 5 seconds, testing a password with the hash at hand takes less than a microsecond. Well, it depends on the hash and how strong the password is ;). But I concur this issue is pretty unimportant. Most security breaches these days occur due to faulty software allowing arbitrary code execution from network input. Or some fault/feature in the operating system allowing circumvention of the login prompt. (If you give me physical access to a Linux box, I'll get access to it.) So knowing a password isn't necessary any more. Exactly. This is a rather trivial issue and for instance not relevant for ssh, telnet and other means of non-local access. Cheers FRIGN -- FRIGN d...@frign.de
Re: [dev] [PATCH] [ubase] Simplify login
On Mon, Jun 02, 2014 at 06:41:45PM +0200, FRIGN wrote: […] If your password is strong, having the hashes won't help any attacker. […] I think that's the whole point. Hashing the password before writing it to disk does not hurt much. In case an attacker got access to a box he does not know what password the users chose. Maybe that's a low value, but it's a value, … for a relatively low price. What here provides a false feeling of security? Kind regards, -Alex
Re: [dev] [PATCH] [ubase] Simplify login
On Tue, 3 Jun 2014 22:44:31 +0200 Alexander Huemer alexander.hue...@xx.vu wrote: What here provides a false feeling of security? Well, the incorporation of this shadow-file. Some users might see this as a motivation for weak passwords. Cheers FRIGN -- FRIGN d...@frign.de
Re: [dev] [PATCH] [ubase] Simplify login
On Wed, Jun 04, 2014 at 12:12:51AM +0200, FRIGN wrote: On Tue, 3 Jun 2014 22:44:31 +0200 Alexander Huemer alexander.hue...@xx.vu wrote: What here provides a false feeling of security? Well, the incorporation of this shadow-file. Some users might see this as a motivation for weak passwords. You think so? That's not at all what I personally associate with this feature. Can you elaborate? Kind regards, -Alex
[dev] [PATCH] [ubase] Simplify login
Hello,
I was very glad to see the initial implementation of login by sin, but
found some stuff that simplifies the code even more.
Check the patch for more details, it should speak for itself.
Cheers
FRIGN
--
FRIGN d...@frign.de
From b39d86ebdaadfe4880fd1681bd021ea06ecadb75 Mon Sep 17 00:00:00 2001
From: FRIGN d...@frign.de
Date: Mon, 2 Jun 2014 18:04:12 +0200
Subject: [PATCH] Simplify login
Remove some unnecessary local values, simplify the exec-call at the end
(we don't need the separate array) and print clearer and more consistent
error-messages.
---
login.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/login.c b/login.c
index 3adf188..40140ab 100644
--- a/login.c
+++ b/login.c
@@ -24,8 +24,6 @@ int
main(int argc, char *argv[])
{
struct passwd *pw;
- uid_t uid;
- gid_t gid;
char *pass, *cryptpass;
int pflag = 0;
@@ -50,15 +48,12 @@ main(int argc, char *argv[])
switch (pw-pw_passwd[0]) {
case '!':
case '*':
- eprintf(Denied\n);
+ eprintf(denied\n);
}
if (pw-pw_passwd[0] == 'x' pw-pw_passwd[1] == '\0')
eprintf(no shadow support\n);
- uid = pw-pw_uid;
- gid = pw-pw_gid;
-
/* Empty password? Login now */
if (pw-pw_passwd[0] == '\0')
goto login;
@@ -75,14 +70,14 @@ main(int argc, char *argv[])
if (!cryptpass)
eprintf(crypt:);
if (strcmp(cryptpass, pw-pw_passwd) != 0)
- eprintf(oops\n);
+ eprintf(login failed\n);
login:
- if (initgroups(argv[0], gid) 0)
+ if (initgroups(argv[0], pw-pw_gid) 0)
eprintf(initgroups:);
- if (setgid(gid) 0)
+ if (setgid(pw-pw_gid) 0)
eprintf(setgid:);
- if (setuid(uid) 0)
+ if (setuid(pw-pw_uid) 0)
eprintf(setuid:);
return dologin(pw, pflag);
@@ -91,8 +86,6 @@ login:
static int
dologin(struct passwd *pw, int preserve)
{
- char *shell[] = { pw-pw_shell, pw-pw_shell, -l, NULL };
-
if (preserve == 0)
clearenv();
setenv(HOME, pw-pw_dir, 1);
@@ -103,7 +96,7 @@ dologin(struct passwd *pw, int preserve)
ENV_SUPATH : ENV_PATH, 1);
if (chdir(pw-pw_dir) 0)
eprintf(chdir %s:, pw-pw_dir);
- execvp(shell[0], shell + 1);
- weprintf(execvp %s:, shell[0]);
+ execlp(pw-pw_shell, pw-pw_shell, -l, NULL);
+ weprintf(execvp %s:, pw-pw_shell);
return (errno == ENOENT) ? 127 : 126;
}
--
1.8.5.5
Re: [dev] [PATCH] [ubase] Simplify login
On Mon, Jun 02, 2014 at 06:08:12PM +0200, FRIGN wrote: Hello, I was very glad to see the initial implementation of login by sin, but found some stuff that simplifies the code even more. Check the patch for more details, it should speak for itself. Thanks. Yeah the uid, gid stuff are leftovers because I initially had shadow support but could not be arsed to test it so I removed it.
Re: [dev] [PATCH] [ubase] Simplify login
On Mon, Jun 02, 2014 at 06:08:12PM +0200, FRIGN wrote: Hello, I was very glad to see the initial implementation of login by sin, but found some stuff that simplifies the code even more. Check the patch for more details, it should speak for itself. Applied thanks. We should probably factor out some of the common code between login and su into util along with shadow+plain support.
Re: [dev] [PATCH] [ubase] Simplify login
On Mon, Jun 02, 2014 at 06:20:52PM +0200, FRIGN wrote: On Mon, 2 Jun 2014 17:13:49 +0100 Dimitris Papastamos s...@2f30.org wrote: Yeah the uid, gid stuff are leftovers because I initially had shadow support but could not be arsed to test it so I removed it. I don't see the reason behind shadow-support. Well, the purpose is to prevent bruteforcing the password. However, it's not like a simple login would stop you anyway. If you want to get someone's data, just mount the drive somewhere else and access it directly. I don't care personally. We should definitely add /etc/passwd support to su though because currently it only works with /etc/shadow.
Re: [dev] [PATCH] [ubase] Simplify login
On Mon, 2 Jun 2014 17:13:49 +0100 Dimitris Papastamos s...@2f30.org wrote: Yeah the uid, gid stuff are leftovers because I initially had shadow support but could not be arsed to test it so I removed it. I don't see the reason behind shadow-support. Well, the purpose is to prevent bruteforcing the password. However, it's not like a simple login would stop you anyway. If you want to get someone's data, just mount the drive somewhere else and access it directly. I may be wrong, so please correct me if there really are some good use-cases. Running pwunconv is trivial, so it's not a hard dependency. Cheers FRIGN -- FRIGN d...@frign.de
Re: [dev] [PATCH] [ubase] Simplify login
On Mon, 2 Jun 2014 17:23:03 +0100 Dimitris Papastamos s...@2f30.org wrote: I don't care personally. We should definitely add /etc/passwd support to su though because currently it only works with /etc/shadow. Well, I prefer /etc/passwd, given it gives a false feeling of security using the shadow-file. In reality, it's a solution for a very unimportant issue. If your password is strong, having the hashes won't help any attacker. On the other hand, having a weak password, the shadow-file doesn't save you from a breach. Cheers FRIGN -- FRIGN d...@frign.de
