On Thu, Jul 12, 2012 at 7:21 AM, C Anthony Risinger wrote:
> However PAM, also by design, works in stacks, and thus offers a reasonable
> solution -- update the `auth` and `password` PAM keys to the new algo (so
> new passwords are read/written properly) then duplicate the `auth` key,
> restore th
On Thu, Jul 12, 2012 at 1:35 PM, Kevin Chadwick wrote:
>
> When upgrading to a stronger hash I have never tested if it stops you
> from using the same password when the hashes are different because it
> matches both but I expect, that would be how it works. Is that the
> issue? In that usually you
> It does. But is is still two steps. This isn't really a problem
> though, just out of curiosity.
Fair enough.
I don't understand the reason to want to do this, am I missing
something aside from why should the system stop you when it could just
warn you (similar to requirements for root).
When
On Thu, Jul 12, 2012 at 11:43 AM, Kevin Chadwick wrote:
>
> Does passwd -d work.
>
It does. But is is still two steps. This isn't really a problem
though, just out of curiosity.
--Chris Sakalis
> 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 passwor
On Jul 11, 2012 3:06 AM, "Chris Sakalis" wrote:
> On Wed, Jul 11, 2012 at 11:16 AM, Kevin Chadwick
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 star
On Wed, Jul 11, 2012 at 11:16 AM, Kevin Chadwick 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 wha
> 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 b
By the way, is it possible to upgrade password hashes without an
intermediate password, assuming the new/old passwords are identical?
> 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
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 o
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
Î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
On Mon, Jan 23, 2012 at 6:30 AM, Kevin Chadwick 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 PA
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
-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 comp
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
especi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/23/2012 12:59 PM, Kevin Chadwick wrote:
> OpenBSDs bcrypt with configurable rounds is awesome by the way and far
> more secure, yet wouldn't pass PCI compliance, how dumb some of these
> certifications are.
I know next to nothing about bcrypt, b
On Sat, 21 Jan 2012 17:50:13 +0100
Tobias Frilling wrote:
> The CRYPT setting from /etc/default/passwd is only used if pam is not
> enabled. If it is enabled, the used configs are in /etc/pam.d (e.g.
> passwd, login etc.) which default nowadays to sha512.
Confirmed, /etc/default/passwd does not
On Sat, Jan 21, 2012 at 08:06:04AM -0800, Don Juan wrote:
> On 01/21/2012 07:34 AM, Mantas M. wrote:
> >On Fri, Jan 20, 2012 at 11:04:12PM +, Kevin Chadwick wrote:
> >>Maybe I missed giving a piece of info. The default password is DES which
> >>is really crap and starts with $1 so simply enabli
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/21/2012 05:06 PM, Don Juan wrote:
> Then if the default is that then why are default system users, such as
> http mail postfix and similar not displaying the $1$ on the shadow file?
> Also according to the wiki it says des is the default and to u
On 01/21/2012 07:34 AM, Mantas M. wrote:
On Fri, Jan 20, 2012 at 11:04:12PM +, Kevin Chadwick wrote:
Maybe I missed giving a piece of info. The default password is DES which
is really crap and starts with $1 so simply enabling blowfish
DES is indeed crap, but it hasn't been the default for
On Fri, Jan 20, 2012 at 11:04:12PM +, Kevin Chadwick wrote:
> Maybe I missed giving a piece of info. The default password is DES which
> is really crap and starts with $1 so simply enabling blowfish
DES is indeed crap, but it hasn't been the default for a long time.
The $1$ hashes are salted M
On 01/20/2012 03:04 PM, Kevin Chadwick wrote:
On Fri, 20 Jan 2012 14:17:22 -0800
Don Juan wrote:
Not sure if I am getting what you mean here but to me sounds like you
did not complete what is in the wiki in regards to running blowfish,
since you need AUR package and what not and it says there i
On Fri, 20 Jan 2012 14:17:22 -0800
Don Juan wrote:
> Not sure if I am getting what you mean here but to me sounds like you
> did not complete what is in the wiki in regards to running blowfish,
> since you need AUR package and what not and it says there is more to do
> than change a single file
On 01/20/2012 04:32 AM, Kevin Chadwick wrote:
I know arch tries to keep to upstream but their seems some
discrepencies that you may or may not be aware of so thought I'd share.
The crypt man page says glibc may not support blowfish (stronger than
nists recommendation) and that seems true when us
I know arch tries to keep to upstream but their seems some
discrepencies that you may or may not be aware of so thought I'd share.
The crypt man page says glibc may not support blowfish (stronger than
nists recommendation) and that seems true when used via the commandline
(very short output).
The
27 matches
Mail list logo
