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
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
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
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.
--
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
26 matches
Mail list logo
