On Mon, 23 Jan 2012 13:09:33 +0100
Tobias Frilling wrote:

> I know next to nothing about bcrypt, but you can configure rounds in pam

I could say similar about pam. In OpenBSD rounds are in plain sight in
/etc/login.conf

The PAM documentation I've found seems incomplete and a bit ambiguous
especially if you edit /etc/pam.d/other and make it explicit. I've been
wondering if that has anything to do with the Support companies that are
so involved with Linux, with it paying to be less straight forward. Do
you know of a good reference for PAM?

--
Kc

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/23/2012 01:30 PM, Kevin Chadwick wrote:
> The PAM documentation I've found seems incomplete and a bit ambiguous
> especially if you edit /etc/pam.d/other and make it explicit. I've been
> wondering if that has anything to do with the Support companies that are
> so involved with Linux, with it paying to be less straight forward. Do
> you know of a good reference for PAM?

The rounds options is documented in pam_unix(8). If you want something
along "The Sysadmins Guide to PAM" search for pam at
http://www.linuxtopia.org, they have some manual from SLES, Red Hat etc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPHVZ4AAoJEEDINPnaM7l+mZIIAI1fbGJiGh nxvr1+N+I9BNPT
RuGifa5BqLKDhFP9L+vSghTxRdpVXV9M/HCFpMISX77pm4g0eP7+dtfV2ZF12pa0
gOEIZcg7AFQa0KFCt2JQAJzpjgAM6ntg42RqIQNFdUWKYfHsjC MpUEdoJpDfd/Gk
baGW3u8hCzYY3rbo2BYTPAnnISqLpZ6RHqiFAihB6n1lzA8587 kkZRql6TxK2gr4
O+3ggwkUX57lL353kvPK2cZUfUf3cIJpsGjxHIQlltZrvhWcZN 8bSzk8hwOlW9YZ
jYKaqf3I49kc08ivC93OxzCVoASRm6IsURENMi9XN/9gbt2LLZPYS4hUzoXxhg0=
=uJAF
-----END PGP SIGNATURE-----

I believe that if not specified, the default number of rounds is 5000.

I edit /etc/default/passwd [0] and /etc/pam.d/password [1], to be sure
and hope for the best. I also add these lines [2], taken from the Debian
version of the file, to /etc/login.defs.

I've been doing this for about a year or so and I always wondered why
the default in Archlinux was to use MD5 in /etc/pam.d/passwd and DES
in /etc/default/passwd. I see that using DES in /etc/default/passwd is
still the case.

[0] http://ompldr.org/vY2VycA
[1] http://ompldr.org/vY2Vyag
[2] http://ompldr.org/vY2VyeA

--
<>< Sorin-Mihai Vârgolici
Proud member of Ceata (http://ceata.org/)
Arcada developer (https://arcadaproject.org/)

On Mon, Jan 23, 2012 at 6:30 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> On Mon, 23 Jan 2012 13:09:33 +0100
> Tobias Frilling wrote:
>
>> I know next to nothing about bcrypt, but you can configure rounds in pam
>
> I could say similar about pam. In OpenBSD rounds are in plain sight in
> /etc/login.conf
>
> The PAM documentation I've found seems incomplete and a bit ambiguous
> especially if you edit /etc/pam.d/other and make it explicit. I've been
> wondering if that has anything to do with the Support companies that are
> so involved with Linux, with it paying to be less straight forward. Do
> you know of a good reference for PAM?

login.defs is provided by the `shadow` package, not `pam`, and details
these options:

ENCRYPT_METHOD, SHA_CRYPT_MIN_ROUNDS, SHA_CRYPT_MAX_ROUNDS

... but it's not clear that the `shadow` option to pam_unix.so honors
these values, only that pam_unix.so will "Try to maintain a shadow
based system", which sounds more like a compatibility statement.

it's important to note that bcrypt != blowfish (modified blowfish used
internally), and also understand hashing != encryption. sha512 is a
parameter-less hash function, blowfish is a parameterized [keyed]
block cipher, and bcrypt is a blowfish-based effectively-hash-like
encryption of *known* plaintext. both hashes computationally FUBAR
your password's to infeasible realms -- blowfish the cipher cannot be
compared directly.

further:

http://stackoverflow.com/a/1561245/404019
http://en.wikipedia.org/wiki/Bcrypt

... i can't find any literature suggesting sha512 decreases your
security, and no reason to bother switching. both are good solutions.

`man pam_unix` will give you a good overview of PAM, simply because
it's the primary module responsible for traditional, file-based login.
in a nutshell, PAM looks at the requester's name (the binary), loads
a config with the same name from /etc/pam.d/{name}, and finally pipes
your activities through each defined modules in four groups:

account: whoa buddy, i'll need to verify {user} can even access
service {name}, first.
authentication: ooook, but are you who you claim to be?
password: uhm, if you want to update {user} creds, you'll have to go
thru me first, pal.
session: welcome masta' {user}! let me get the door when entering and leaving!

... that's about all there is to it. normally each module must
succeed, but they can also be flagged optional, and there is a massive
number of available modules to inject at any point, from time-of-day
denial to obsure password storage devices like OTP/smart cards,
whatever, and anything else you can dream up.

--

C Anthony

În data de Lu, 23-01-2012 la 18:08 -0600, C Anthony Risinger a scris:
> login.defs is provided by the `shadow` package, not `pam`, and details
> these options:
>
> ENCRYPT_METHOD, SHA_CRYPT_MIN_ROUNDS, SHA_CRYPT_MAX_ROUNDS

These options aren't in the Archlinux version of the login.defs file,
like I said in my previous message. No ideea why.

> ... but it's not clear that the `shadow` option to pam_unix.so honors
> these values, only that pam_unix.so will "Try to maintain a shadow
> based system", which sounds more like a compatibility statement.

I wonder, is there anyone still not using pam?

> ... i can't find any literature suggesting sha512 decreases your
> security, and no reason to bother switching. both are good solutions.

It might be because of the FUD that OpenBSD is the only secure OS, which
isn't the case; I think they still don't provide full disk encryption,
of any kind.

Yeah, kinda off-topic, I know.

--
<>< Sorin-Mihai Vârgolici
Proud member of Ceata (http://ceata.org/)
Arcada developer (https://arcadaproject.org/)

On Tue, 24 Jan 2012 03:01:09 +0200
Sorin-Mihai Vârgolici wrote:

> It might be because of the FUD that OpenBSD is the only secure OS, which
> isn't the case; I think they still don't provide full disk encryption,
> of any kind.

That has next to nothing to do with security, lets not open that can of
worms, we'd be here all day.

--
Kc

On Mon, 23 Jan 2012 18:08:56 -0600
C Anthony Risinger wrote:

> further:
>
> http://stackoverflow.com/a/1561245/404019
> http://en.wikipedia.org/wiki/Bcrypt
>
> ... i can't find any literature suggesting sha512 decreases your
> security, and no reason to bother switching. both are good solutions.
>

Certainly not worth the effort to me right now, you might be interested
or already know about this though.

"http://www.openbsd.org/papers/bcrypt-paper.pdf"


> `man pam_unix` will give you a good overview of PAM, simply because
> it's the primary module responsible for traditional, file-based login.
> in a nutshell, PAM looks at the requester's name (the binary), loads
> a config with the same name from /etc/pam.d/{name}, and finally pipes
> your activities through each defined modules in four groups:

Thanks for the info. I find it time-consuming to see what is allowed
and prevented with udev, pam and dbus, polkit etc.. With sudo for
example, it is easy.

--
Kc

> further:
>
> http://stackoverflow.com/a/1561245/404019
> http://en.wikipedia.org/wiki/Bcrypt
>
> ... i can't find any literature suggesting sha512 decreases your
> security, and no reason to bother switching. both are good solutions.

This is interesting WRT memory usage. Whether it's a reason to bother
switching or coding in the first place is still debatable of course.

http://www.h-online.com/security/news/item/John-the-Ripper-now-able-to-crack-office-files-and-use-GPUs-1631901.html

--
__________________________________________________ ______

Why not do something good every day and install BOINC.
__________________________________________________ ______

By the way, is it possible to upgrade password hashes without an
intermediate password, assuming the new/old passwords are identical?

On Wed, Jul 11, 2012 at 11:16 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>> By the way, is it possible to upgrade password hashes without an
>> intermediate password, assuming the new/old passwords are identical?
>
> You can have no password at all to start with but the system doesn't
> know the password, only what you entered matches. You could attack the
> md5 but that would be a waste of energy and likely time.
>

I do not think that this is what Nemo is asking. If you try to set
your password to the same one you already have, passwd fails with
"Password unchanged" and asks you again for a new password. So, if you
just want to update your hashes, you have to choose an intermediate
temporary password first and then change it again to the old one.