July 2002 - openSUSE Security - openSUSE Mailing Lists

Request for comment: Custom MD5 password hashes
by Scott Courtney 12 Jul '02

12 Jul '02

Good morning. I am in the process of implementing a custom authentication system for an Open Source web application. I do not have the option in this app of using existing frameworks such as PAM or LDAP or Kerberos, and the need for security is only moderate because the data being protected is not especially sensitive. Still, I want it to be the best that it can be given the constraints of the environment. What I propose, with regard to password hashing, is something like this: Let string1 = login . "\n" . password . "\n" . iso_timestamp_string (example: "myaccount\nV3rY53cr37\n20020712094952") Let hash = md5sum(string1) Store login . "\n" . iso_timestamp_string . "\n" hash in the equivalent of the shadow file. (example: "myaccount\n20020712094952\na66c43e395f555447aad298a538f5e38") The idea is that (1) two users who have the same password will get different has values and (2) the same password reselected by the same user at different times will yield different hash values. The weakness I see in this is that monotonically-increasing time values are poor in entropy, but my thinking is that entropy will not be the weak link here. Rather, I expect the weak link to be the users themselves and their choice of poor passwords. Again, the data is not especially sensitive -- just user preferences and the like. Is what I propose "good enough" for this application, even though it might not be ideal and certainly is not good enough for financial or other critical applications? If people consider this off-topic, I apologize. I am starting with SuSE as the basis for building the system, and it is security-related, so I hope you will find it to be on-topic. Thanks for any comments people care to offer. Kind regards, Scott -- -----------------------+------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them courtney(a)4th.com | having a bad operating system." -- Linus Torvalds http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) | PGP Public Key at http://4th.com/keys/courtney.pubkey

2 1

harden_suse and suse 8.0
by Oliver Ziltener 12 Jul '02

12 Jul '02

Hello has anybody experience with harden_suse on suse 8.0. According to the messages of harden_suse is harden_suse only ready for 5.3 - 7.2: linux2:# harden_suse Guessing you are using SuSE version 8.0 WARNING: You seemed to have installed a SuSE version which is not yet supported by this hardening script! (Verified to work with 5.3 up to 7.2) Try to get an update from ftp://ftp.suse.com or http://www.suse.de/~marc ... Use at own risk! thanks for any info Oliver

1 0

Re: [suse-security] Samba and SuSE Firewall 2
by Philippe Vogel 12 Jul '02

12 Jul '02

Oops, I forgot something in my mail! Where to add this to: Add following line to /etc/rc.config.d/firewall2.rc.config LOCALNET_1="123.123.123.0/24" to allow net 123.123.123.0/24 Access to local Samba Server. Must be change to your needs! For Complex Networks you have to make a filter rule and a log rule for each subnet. Take the example from the other mail! Better make a test before that with: /sbin/SuSEfirewall2 test If no error come, then you have typed in all letters correct and the firewall can be restartted! /sbin/SuSEfirewall2 stop /sbin/SuSEfirewall2 start This flushes the rules. Sometimes the rcSuSEfirewall2 leaves single chains unflushed! Philippe P.S.: I changed the log-name-entry for /var/log/firewall in my rule, because I use fireparse.pl for Mailing reports to me, so leave this as is in the Script! P.S.S.: This change is made to your own risk. At my servers it works! The "deny all" - rules later in the script deny any other PC's to access samba, so you only have to allow, what is allowed. There is no need to insert deny-rules there.

1 0

Re: [suse-security] Request for comment: Custom MD5 password hashes
by Scott Courtney 12 Jul '02

12 Jul '02

On Friday 12 July 2002 10:26 am, Alan Rouse wrote: > You'd be better off using a random function to generate the salt, rather > than using a timestamp. Assuming your computer's clock is set somewhere > close to true time (or that the delta can be learned), if I know when > you changed your password I could use this information to accelerate my > attack by making informed guesses about the salt value. This is a very good point. Now that I think about it, a field in the database will have the last password change timestamp in cleartext, to support things like password expirations. So this will be an especially important issue on this system. I'll use /dev/random to generate salt (though it's not truly "salt" in the crypt() sense, if I understand correctly the prior discussion of that function). The good news is that on a web server there should be plenty of entropy to make /dev/random a good entropy source. Thanks for the comments. As you mention in your second note, this is probably a non-issue given the low criticality of my data, but since it is so easy to fix the vulnerability, there is no reason not to do so. Scott -- -----------------------+------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them courtney(a)4th.com | having a bad operating system." -- Linus Torvalds http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) | PGP Public Key at http://4th.com/keys/courtney.pubkey

1 0

FW: [suse-security] Request for comment: Custom MD5 password hashes
by Alan Rouse 12 Jul '02

12 Jul '02

I must need some more coffee this morning. The weakness is that I could (in advance) create a reasonable-sized dictionary (maybe a billion entries, a few gigabytes total) using salts consisting only of timestamps chosen near the expected time. When I begin the attack on your hashed password, my odds of having your hash in my dictionary might be pretty good. But that's a lot of work to attack something that you said is not especially sensitive, so maybe it is a non-issue. -----Original Message----- From: Alan Rouse Sent: Friday, July 12, 2002 10:31 AM To: suse-security(a)suse.com Subject: RE: [suse-security] Request for comment: Custom MD5 password hashes Scott Courtney wrote: > What I propose, with regard to password hashing, is something like this: > > Let string1 = login . "\n" . password . "\n" . iso_timestamp_string > > (example: "myaccount\nV3rY53cr37\n20020712094952") > > Let hash = md5sum(string1) > Store login . "\n" . iso_timestamp_string . "\n" hash in the equivalent > of the shadow file. > (example: "myaccount\n20020712094952\na66c43e395f555447aad298a538f5e38") You'd be better off using a random function to generate the salt, rather than using a timestamp. Assuming your computer's clock is set somewhere close to true time (or that the delta can be learned), if I know when you changed your password I could use this information to accelerate my attack by making informed guesses about the salt value. Of course if your random function is seeded with the timestamp then the two are equivalent. Depending on your platform, if you use the unix /dev/random, or the java SecureRandom class you should be in great shape.

1 0

RE: [suse-security] Request for comment: Custom MD5 password hashes
by Alan Rouse 12 Jul '02

12 Jul '02

Scott Courtney wrote: > What I propose, with regard to password hashing, is something like this: > > Let string1 = login . "\n" . password . "\n" . iso_timestamp_string > > (example: "myaccount\nV3rY53cr37\n20020712094952") > > Let hash = md5sum(string1) > Store login . "\n" . iso_timestamp_string . "\n" hash in the equivalent > of the shadow file. > (example: "myaccount\n20020712094952\na66c43e395f555447aad298a538f5e38") You'd be better off using a random function to generate the salt, rather than using a timestamp. Assuming your computer's clock is set somewhere close to true time (or that the delta can be learned), if I know when you changed your password I could use this information to accelerate my attack by making informed guesses about the salt value. Of course if your random function is seeded with the timestamp then the two are equivalent. Depending on your platform, if you use the unix /dev/random, or the java SecureRandom class you should be in great shape.

1 0

bind upgrade on 7.1
by Chad Whitten 12 Jul '02

12 Jul '02

i upgraded bind8 to the latest version on the suse ftp site this morning (as well as the bindutils package) and now i cant run nslookup with the nameserver set to 127.0.0.1. I installed the bindutils package and then did an nslookup and it worked fine. installed the new bind package and restarted bind and could not do nslookup. changed ip in /etc/resolv.conf to ip of ethernet interface on machine and i could do a lookup and the machine resolves queries from remote hosts so this is really no big deal, just wondering if anyone else had experienced it and had a workaround/solution. -- Chad Whitten Network/Systems Administrator neXband Communications cwhitten(a)nexband.com

1 0

RE: [suse-security] Password Encryption
by Alan Rouse 12 Jul '02

12 Jul '02

Tobias wrote: > However, since the salt is stored in plaintext in the shadow file, if you > get that, the advantage of salt disappears. Salt has no effect on the difficulty of attacking from a password prompt. It is only useful in attacks against the shadow file. Salt still increases the effort to attack a shadow file even though the salt is plainly visible. It greatly increases the cost of building a dictionary in advance, since it now has to be 4096 times larger. In effect it means the computational effort has to begin after you obtain the shadow file. It means an attacker can't prepare a dictionary, then use it repeatedly forever to look up passwords on every shadow file he can steal. The effort must be repeated on each occasion. Realistically, if the attacker has the means to obtain a shadow file (ie root) he probably doesn't need to crack a password. But if you are not using shadow files, your password file is a valuable target accessible to any user, not just root. Larger salt would be better... 4096 probably is not a large enough factor nowadays. LDAP uses 8 to 16 bytes of salt.

1 0

mount sambashare with non-root-user
by ic_admin 12 Jul '02

12 Jul '02

Hello, I want to mount a samba-share in my linux-box but don't want do this as root. I put an entry in my /etc/fstab like this: "//smbserver/share /mnt smbfs username=abc,password=abc,uid=500,gid=100,rw,noauto,users,exec 0 0" ... and I am able to mount this share as root and root is not the owner of the files. BUT when I try to mount this as an user I get the error message: "cannot mount on /mnt: operation is not allowed". Does anybody know a way to do this with a standard user? Thanks and regards Ruediger

3 2

Samba and SuSE Firewall 2
by Z_God 12 Jul '02

12 Jul '02

I'm upgrading from SuSE 6.4 (with the original SuSE Firewall) to SuSE 7.3 (with SuSE Firewall 2). With my 6.4 configuration I had the firewall set up so that it wasn't protected against the internal network and that all computers on my internal network had access to the printer using Samba. From the outside nobody could see I was running Samba according to several sercurity checks on the internet. But with the new SuSE Firewall 2 I unable to get this to work. When I set FW_SERVICE_SAMBA, Samba works perfectly for the internal network, but from the outside, it is possible to get the Netbios name. When I disable FW_SERVICE_SAMBA, everything is secure, but computers from the internal network do not work with Samba anymore. I also haven't protected the new firewall against the internal network. Is it possible to get Samba to work like it did with the old Firewall, from outside nothing, from inside everything? Thanks in advance.

2 3