Hash: SHA512

On 03/07/14 15:07, John-Mark Gurney wrote:
> Allan Jude wrote this message on Fri, Mar 07, 2014 at 17:53 -0500:
>> On 2014-03-07 17:06, Xin Li wrote:
>>> Hi,
>>> On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote:
>>>> Allan Jude wrote:
>>>>> On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote:
>>>>>> Allan Jude wrote:
>>>>>> [...]
>>>>>>> Honestly, my use case is just silently upgrading the
>>>>>>> strength of the hashing algorithm (when combined with
>>>>>>> my other feature request). Updating my bcrypt hashes
>>>>>>> from $2a$04$ to $2b$12$ or something. Same applies for
>>>>>>> the default sha512, maybe I want to update to
>>>>>>> rounds=15000
>>>>>> Like this?
>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=182518
>>>>>> Request for comments:
>>>>>> http://docs.freebsd.org/cgi/mid.cgi?20140106205156.GD4903
This looks like what we wanted. In the feedback you talked about
>>>>> some changes to your patch required to make it work, is
>>>>> there any progress on those?
>>>> Derek's patches worked perfectly for our needs, but we're the
>>>> sort of people who use vipw and our own utilities for user
>>>> management. It wasn't until later that we discovered at least
>>>> one other file would need patching to satisfy everyone.  We
>>>> didn't want to employ the same copy-pasta method, so we asked
>>>> for feedback about our proposed alternative.
>>>> secteam@, do you have any comments?  Before we put any more
>>>> work into this, we want to be sure that our proposal is an
>>>> acceptable one.
>>> Did you mean adding rounds capability, or transparent upgrade
>>> of crypt() algorithms, or both?
>> There are 2 separate but related threads
>> 1) specify rounds for crypt()
>> 2) transparent upgrade of crypt() algo (or more likely just
>> number of rounds)
> Can't the two be merged...  where 2 becomes a flag in login.conf
> instead of an algo fetch, and then if it's true, it does the algo
> fetch from 1?
> I really would like us to get 1 in, and then on boot dynamicly
> adjust the number of rounds depending upon CPU usage... obviously,
> a flag will adjust how long/many rounds the admin wants, but it
> would allow an automatic increase in security as faster CPUs are
> used...

Or by the installer/a tool that gets run when doing
mergemaster/etcupdate/freebsd-update: it's rare that CPU gets faster
after installation, and we can probably just write in the
configuration anyway?

Personally I'm not a big fan of making it something that changes over
time: the attacker may do offline attacker than doing it on the victim
system that revealed the salted hashes, so how fast the system CPU
runs doesn't really matter, except for how long a system administrator
is willing to have the user to wait.

> Anyways, how many people are still using passwords instead of ssh
> keys? Setting the time to be something like 100ms may seem long,
> but considering few people should be using passwords these days,
> it's less of an issue...

I'm currently using SSH key plus Google Authenticator for my systems
but all remote login via password is disabled.  I am aware of,
however, many people who refuse to use SSH key authentication because
they don't want to carry their keys, which is a bad idea but they do
it anyways.

> Xin Li, if you need help reviewing, testing, let me know...

Will do and thanks for the offer!

- -- 
Xin LI <delp...@delphij.net>    https://www.delphij.net/
FreeBSD - The Power to Serve!           Live free or die
Version: GnuPG v2.0.22 (FreeBSD)

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to