Discussion about a reasonable API is ongoing, but I'll give some
review comments anyway -- including some of my thoughts on why the
crypt_r API is not ideal -- in case they're helpful.
--- include/unistd.h 15 Oct 2021 22:32:28 - 1.162
+++ include/unistd.h 12 Feb 2022 12:47:04
> Date: Wed, 16 Feb 2022 10:27:08 -0500 (EST)
> From: Mouse
>
> > Thi is an essential hardening step against FPGA/custom ASIC
> > implementations.
>
> I can't help feeling that there should be better ways to do that. I
> like the idea of resistance to such things, but, for at least my
>
On Wed, Feb 16, 2022 at 10:27:08AM -0500, Mouse wrote:
> That sounds like a recipe for disaster. It is a complete fail for
> heterogenous environments where the same hash needs to be checkable on
> widely disparate hardware, where a small machine may not have the
> resources to perform the check
> Given that malloc will cache any reasonable small allocation anyway,
> we are talking about a few dozen or 100 cpu cycles for an operation
> that is expected to take several orders of magnitude more.
I wouldn't be concerned about CPU time costs, no. I'm more concerned
about malloc _failing_.
> All modern password hashing algorithms use a large memory buffers and
> will attempt to scale them according to system ressources.
So merely attempting to log in *requires* a major fraction of the
amount of memory the system had when the password was set?
That sounds like a recipe for
Am Tue, Feb 15, 2022 at 05:25:10PM -0800 schrieb Konrad Schroder:
> Of course the clearest use-case for crypt_r(3) is a password cracker: each
> thread sets up its own local memory and blasts through calls to crypt_r(3)
> as fast as it can. I've run a cracker as a white-hat. But
Am Tue, Feb 15, 2022 at 08:04:29PM -0500 schrieb Mouse:
> > Given that the goal of the crypt(3) interface is to be slow,
> > optimizing a memory allocation away saves nothing, except making a
> > more complicated interface.
>
> I disagree. It saves a bunch of error paths. Many (most? all?) of
Am Tue, Feb 15, 2022 at 03:58:30PM -0800 schrieb Jason Thorpe:
> There really should be a function that takes a user name or ID and a
> cleartext password string, and IPCs to another (trusted system) process
> to do the verification, so that programs that want to verify passwords
> don’t need root
> On Feb 15, 2022, at 5:13 PM, Mouse wrote:
>
>> There really should be a function that takes a user name or ID and a clearte$
>
> Maybe. But then you have a lot more failure modes and a lot more
> possible attack surface. It would also mean that you can't check or
> change passwords in
get crypt_r(3) as described.
Of course the clearest use-case for crypt_r(3) is a password cracker:
each thread sets up its own local memory and blasts through calls to
crypt_r(3) as fast as it can. I've run a cracker as a white-hat. But I
can see not wanting to add the capability to base
> There really should be a function that takes a user name or ID and a clearte$
Maybe. But then you have a lot more failure modes and a lot more
possible attack surface. It would also mean that you can't check or
change passwords in single-user mode without starting the magic daemon;
that would
> There are two sensible interface contracts here:
> (1) Verification only, which takes the password and the expected hash
> and returns a bool. [...]
> (2) Hashing password, which takes the password and the settings and
> returns an allocated string with the resulting hash. [...]
Well, I
> On Feb 15, 2022, at 3:30 PM, Joerg Sonnenberger wrote:
>
> Am Wed, Feb 16, 2022 at 12:04:16AM +0100 schrieb Niclas Rosenvik:
>> do you mean that the interface should be
>> crypt_r(const char *key, const char setting, char * storage, size_t
>> *storage_len)
Am Wed, Feb 16, 2022 at 12:04:16AM +0100 schrieb Niclas Rosenvik:
> do you mean that the interface should be
> crypt_r(const char *key, const char setting, char * storage, size_t
> *storage_len)
> where storage can be set to NULL to return the needed storage size in
&
ed by the filezilla software developer if NetBSD
> > > will add crypt_r() as a thread-safe crypt() replacement.
> > >
> > > Is anyone interested in working on this?
> > > Thomas
> >
> > Here is a cvs diff that implements crypt_r, as mouse pointed out
>
Am Sat, Feb 12, 2022 at 05:25:11PM +0100 schrieb Niclas Rosenvik:
> On Mon, 7 Feb 2022 16:12:17 +0100
> Thomas Klausner wrote:
>
> > Hi!
> >
> > I've been asked by the filezilla software developer if NetBSD will add
> > crypt_r() as a thread-safe crypt(
On Mon, 7 Feb 2022 16:12:17 +0100
Thomas Klausner wrote:
> Hi!
>
> I've been asked by the filezilla software developer if NetBSD will add
> crypt_r() as a thread-safe crypt() replacement.
>
> Is anyone interested in working on this?
> Thomas
Here is a cvs diff th
>> I've been asked by the filezilla software developer if NetBSD will
>> add crypt_r() as a thread-safe crypt() replacement.
> I don't exactly see the point.
Thread safety, presumably. crypt(3) returns a pointer into a static
buffer. I daresay it could be made to return a pointe
Am Mon, Feb 07, 2022 at 04:12:17PM +0100 schrieb Thomas Klausner:
> I've been asked by the filezilla software developer if NetBSD will add
> crypt_r() as a thread-safe crypt() replacement.
I don't exactly see the point. If I wanted to provide a more modern
interface, it would be for pa
Hi!
I've been asked by the filezilla software developer if NetBSD will add
crypt_r() as a thread-safe crypt() replacement.
Is anyone interested in working on this?
Thomas
20 matches
Mail list logo
