Earlier quoted context omitted.
Is 2 KiB really ton of memory?
If you use Argon2 with 2 KiB, there's something really wrong with your parameters.
Argon2 with 2 KiB has more memory hardness than BCRYPT.
Bcrypt at 25
61–70 of 78 posts
Re: Bcrypt at 25
#62Earlier quoted context omitted.
Well, I don't know about that. I really want all algorithms and implementations checked out by at least a few people that write up a report. Even something like Blake3 could be a bit iffy under that criteria.
Blake3 is not, in fact, a bit iffy.
Sure, but the tree structure is "made up" and has had less scrutiny than something than SHA2 SHA384 for example. I use it, but that's where my border line is.
Re: Bcrypt at 25
#63Earlier quoted context omitted.
Background to his desire for open (non locked down) systems (covers the period when the MIT AI lab went from the completely open in-house developed ITS to a proprietary Digital system): https://www.gnu.org/philosophy/stallman-kth.en.html "...But that machine wasn't designed also to support the phenomenon called “tourism.” Now “tourism” is a very old tradition at the AI lab, that went along with our other forms of ana…
That seems naive in the extreme.
It's naïve in our system where problems are not solved as a group, but as a sum of individuals. If you don't trust someone to do something on your computer, then you also probably don't trust them to do much more outside; how can they be a part of the community if they aren't to be trusted ? We have abandoned all community-building to the state, and the state decides collective rules even though the state cannot manage a group this size with the best intents, especially considering the political-economic system we're in; it must assume everyone is problematic by default, and everyone's interest is at odds with the state interest.
Stallman talks about anarchy, a system that seems to have been in place there at the time; one of the central tenet of anarchism is conviviality and building a community together. Everyone who is part of the community is trusted. In this system, you don't need passwords.
Re: Bcrypt at 25
#64It actually wouldn't be that hard to make off the shelf security solutions for free. We just need to take away the developer's choice and force them to integrate with some simple functionality. For example, make a login management framework that is feature-complete and does not require the dev to implement their own "hooks" into its methods. Instead use a config file to tell the framework how to work (expose this HTT…
This sounds more or like like what factotum (https://9fans.github.io/plan9port/man/man4/factotum.html), from plan9, tried to do
Re: Bcrypt at 25
#65Earlier quoted context omitted.
Besides the usual tricks of emailing a magic link or using your 2FA as a super login code, I can see either some sort of hardware token (cost prohibitive for most people) or more likely something like SQRL[0][1]. [0]: https://www.grc.com/sqrl/sqrl.htm [1]: https://en.m.wikipedia.org/wiki/SQRL
> Besides the usual tricks of emailing a magic link Your email still requires password. Besides making it someone else's problem it doesn't solve the issue of not having a password so all the same.
Gmail goes to some pretty extreme lengths to keep you logged in. Yes, you will need a password but that’s not super different from the case of the traditional way to handle this: a password manager.
Re: Bcrypt at 25
#66I'd like to use Argon2 for web stuff but Web Crypto doesn't support it yet ( https://github.com/WICG/proposals/issues/59 ) and the WASM flavor creates problems with bundling and testing. Stuck with PBKDF2 for now...
I wonder if it'd get anywhere. There's not enough CPU/memory allocated in a lot of these platforms to make it work e.g. Deno deploy and Cloudflare workers (bundled) has 50ms of CPU time.
Then that means those platforms are insecure and should not be used, or authentication moved to another layer that does not suffer from those limitations. My rule of thumb is that if authentication does not consistently require at least 1 second, passwords are probably stored insecurely. Fortunately password managers with unique generated passwords limit the blast radius.
Re: Bcrypt at 25
#67bscrypt is a modern alternative to bcrypt; also cache-hard and more suitable than Argon2 and Scrypt: cache-hard, easier to deploy on multi-user environments, as well as web browsers/mobile devices. https://github.com/Sc00bz/bscrypt
The addition of 's' has made it an unfortunate name!
"bs crypto" :))
Re: Bcrypt at 25
#68As one of the creators of bcrypt back in 1997, I find it somewhat surprising that, 25 years later, we still rely heavily on passwords. Not that surprising. It's hard to think of any better alternative. Attempts at replacing passwords results in worse user experience or added complexity.
> It's hard to think of any better alternative.
scrypt is better than bcrypt. it's widely available and it's good enough (though arguably bcrypt is good enough as well)
argon2id is better than both bcrypt and scrypt
Re: Bcrypt at 25
#69Earlier quoted context omitted.
That seems naive in the extreme.
It's naïve in our system where problems are not solved as a group, but as a sum of individuals. If you don't trust someone to do something on your computer, then you also probably don't trust them to do much more outside; how can they be a part of the community if they aren't to be trusted ? We have abandoned all community-building to the state, and the state decides collective rules even though the state cannot mana…
Everyone pretty much is problematic.
Re: Bcrypt at 25
#70Earlier quoted context omitted.
Also, all the standards were crap. HTTP got basic auth, which is crap because plaintext password transmission happens, also the browsers never got around to implement any sensible UI (e.g. you cannot log off). Then it got digest auth, which at least wasn't plaintext in transmission, but required plaintext password storage on the server. Then came negotiate, which only worked with some proprietary products, had even w…
> HTTP got basic auth, which is crap because plaintext password transmission happens... Plaintext submission happens with HTML forms too. The problem with Basic is the password goes with every request. That means you're exposing a long term credential to a higher risk. We want to exchange the long term credential for a short term one, ideally scope limited. That is far less catastrophic to revoke, and gives you some…
Imho WebAuthn is just the next problematic non-solution: Everything you do in WebAuthn you have to build up manually within the already-problematic forms+cookies+serverlogic+javascript stack. You cannot just instruct your webserver to do WebAuthn for /secret and everything works, no, you need tons and tons of code for it to work. Code that will have errors and problems. Code that is lots of complications on top of forms+cookies+serverlogic+javascript.
WebAuthn might solve a problem for the likes of Google and Facebook. But definitely not for the average web developer or server admin. And not for the user of some HTTP-based API. And the problem WebAuthn solves isn't really "we need better Auth", it is rather "we need better customer lock-in". Because the complexity and incompatibility of WebAuthn will just reproduce the debacle that was OpenID, only with the added "bonus" of being coupled to some hardware.