similar to: Password hash rounds solved - important security implications

Two weeks ago I reported a problem I was having in the CentOS 5 Security Support forum. I could not get hash rounds, configured in /etc/libuser.conf, to work on CentOS release 5.10 (Final), 2.6.18-371.3.1.el5 x86_64. The details are here: https://www.centos.org/forums/viewtopic.php?f=24&t=44245&sid=975951a5a0eb264945bbf550ea076278 I read all the documentation and looked for more off the

Two weeks ago I reported a problem I was having in the CentOS 5 Security Support forum. I could not get hash rounds, configured in /etc/libuser.conf, to work on CentOS release 5.10 (Final), 2.6.18-371.3.1.el5 x86_64. The details are here: https:// www.centos.org/forums/viewforum.php?f=24&sid=44859638070165ed5d8d9c35cdbe0378 I read all the documentation and looked for more off the CentOS

In case you are interested, https://wiki.dovecot.org/HowTo/ConvertPasswordSchemes By the way, I am bit sceptical that CRYPT-SHA512 is less secure than PBKDF2. CRYPT-SHA512 is not "just" SHA512(salt||password), it does at least 1000 rounds of hashing in similar way as PBKDF2 does. So, what is your reasoning for claiming that PBKDF2 is much secure than CRYPT-SHA512? Also, if you look

> On October 27, 2017 at 11:27 PM Joseph Tam <jtam.home at gmail.com> wrote: > > > Aki Tuomi wrote: > > > The use of salt, today, is to prevent the attacker from directly seeing > > who has same passwords. Of course it also will make a rainbow table > > attack less useful, > > Not just less useful, but almost infeasible. Given the use of random

Thank you for your reply. It's not that simple, though. Just because some core algorithms are standardised and should be compatible doesn't mean their use in different implementations leads to interoperable data. The key point here seems to be that Dovecot just supports SHA-1 with PBKDF2, not SHA-256. So I'm out of luck here. The different formats are no longer relevant then.

Aki Tuomi wrote: > The use of salt, today, is to prevent the attacker from directly seeing > who has same passwords. Of course it also will make a rainbow table > attack less useful, Not just less useful, but almost infeasible. Given the use of random salts, you would have to generate (number of possible salts) rainbow tables. This drastically changes the CPU/storage tradeoffs. >

> Changing your php app will probably be the easiest solution. Since I?m using Docker, the easiest solution for me is to find a linux distro that can run Dovecot well and supports BLF-CRYPT as well. What Linux distros support BLF-CRYPT and are well tested and secure? > On Jun 5, 2016, at 8:54 PM, Edgar Pettijohn <edgar at pettijohn-web.com> wrote: > > On 16-06-05 20:36:35, KT

>> Maybe, Dovecot could just add support for BLF-CRYPT by using the open source implementation of Blowfish hashing found in https://github.com/php/php-src/tree/master/ext/standard <https://github.com/php/php-src/tree/master/ext/standard>. The implementation looks like a single function to generate the hash. I?m not much of a programmer, but it would seem to me that these .c/.h files

I would go with SHA512-CRYPT, since it is compatible with lots of other things. The field length is static and it contains ascii characters, and it appears to be 118 characters long, but it might be a good idea to use varchar(255) nevertheless, in case you decide to use something else someday. With mysql, you can do mysql> SELECT

> I would love to know why your ubuntu 14.04 system doesn't support sha512-crypt. I just tried SHA512-CRYPT and it is supported on Ubuntu 14.04. I think I was thinking about DBMail instead of Dovecot. I could really use support for BLF-CRYPT since my current password hashes generated by PHP are using Blowfish encryption. Maybe, Dovecot could just add support for BLF-CRYPT by using the

Hello, Thanks for the explanation. So should I go with SSHA512 or SHA512-CRYPT? From your explanation i'm interpreting to mean that SHA512-CRYPT also salts. This is for storing in a mysql database. Also, what should the password field length and type be set for? Currently it's varchar(128) Thanks. Dave. On 4/29/17, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > >> On April

(I subscribed to a daily digest for this list and can?t figure out how to reply to a reply.) Anyway, Aki Tuomi replied to my feature request saying: > We support in latest 2.2 release > > MD5 MD5-CRYPT SHA SHA1 SHA256 SHA512 SMD5 SSHA SSHA256 SSHA512 PLAIN > CLEAR CLEARTEXT PLAIN-TRUNC CRAM-MD5 SCRAM-SHA-1 HMAC-MD5 DIGEST-MD5 > PLAIN-MD4 PLAIN-MD5 LDAP-MD5 LANMAN NTLM OTP SKEY

Lev <leventelist at gmail.com> wrote: > Yes, that was a bit odd. Same password, different hash. Even with > verify tool, there was mismatch. So I decided to go for SHA512, > without encryption. Using user at domain as your ID solved your problem, and this side issue of which hash scheme you're using is probably irrelevant. You misunderstand what {SHA512-CRYPT} does

> On April 29, 2017 at 4:22 AM David Mehler <dave.mehler at gmail.com> wrote: > > > Hello, > > I have a few questions on password schemes. Is SHA512 the most secure? > Is there a difference between SHA512 and SHA512-CRYPT? What about > SSHA512 and SSH512-CRYPT? > > Is there a problem with this sql statement: > > UPDATE virtual_users SET

Hello all, As the holiday season looms upon us, and NUT cracker sounds can be heard everywhere, I wonder if the current codebase is good enough to cut a 2.8.3 release some time soonish. Active development of recently contributed drivers has somewhat subsided; there are still some planned revisions (notably about documentation and statuses for ECO and similar modes), but some more get shelved

Hello all, As the holiday season looms upon us, and NUT cracker sounds can be heard everywhere, I wonder if the current codebase is good enough to cut a 2.8.3 release some time soonish. Active development of recently contributed drivers has somewhat subsided; there are still some planned revisions (notably about documentation and statuses for ECO and similar modes), but some more get shelved

The use of salt, today, is to prevent the attacker from directly seeing who has same passwords. Of course it also will make a rainbow table attack less useful, but then again, no one uses rainbow tables anymore since it takes about few minutes to brute force a password in the cloud or on your home computer GPU. SHA512-CRYPT uses by default 4000 rounds on dovecot, to make it more computationally

> On 29/08/2020 23:49 Yves Goergen <nospam.list at unclassified.de> wrote: > > > Hello, > > I'm setting up a new server and, again, seek for a decently secure (from > a security specialist's POV) way to store and verify user passwords in a > database. Additionally now, GDPR requires me to use a solid > state-of-the-art solution. > > My OS is

We still have MD5 as our default password hash, even though known-hash attacks against MD5 are relatively easy these days. We've supported SHA256 and SHA512 for many years now, so how about making SHA512 the default instead of MD5, like on most Linux distributions? Index: etc/login.conf =================================================================== --- etc/login.conf (revision

OK? So, I have posted on the Centos list, comp.security.ssh, and Linux Forums, and no one seems to have heard of this issue or even have any advice for me. So, I am going to take a shot with the Samba list, since this is related. I have a Centos 6.2 server freshly updated. It is authenticating against an openldap server, and I am having an issue with the hashing algorithms being used by various