SoylentNews is people
SoylentNews
https://www.irregular.com/publications/vibe-password-generation
To security practitioners, the idea of using LLMs to generate passwords may seem silly. Secure password generation is nuanced, and requires care to implement correctly; the random seed, the source of entropy, the mapping of random output to password characters, and even the random number generation algorithm must be chosen carefully in order to prevent critical password recovery attacks. Moreover, password managers (generators and vaults) have been around for decades, and this is exactly what they’re designed to do.
At the heart of any strong password generator is a cryptographically-secure pseudorandom number generator(CSPRNG), responsible for generating the password characters in such a way that they are very hard to predict, and are drawn from a uniform probability distribution over all possible characters.
Conversely, the LLM output token sampling process is designed to do exactly the opposite. Basically, all LLMs do is iteratively predict the next token; the random generation of tokens is, by definition, predictable (with the token probabilities decided by the LLM), and the probability distribution over all possible tokens is very far from uniform.
In spite of this, LLM-generated passwords are likely to be generated and used. First, with the explosive growth and significant improvement in capabilities of AI over the past year (which, at Irregular, we have also seen direct evidence of in the offensive security domain), AI is much more accessible to less technologically-inclined users. Such users may not know secure methods for password generation, not place importance on them, and rely on ubiquitous AI tools to generate a password instead of looking for a specialized tool, such as a password manager. Moreover, while LLM-generated passwords are insecure, they appear strong and secure to the untrained eye, exacerbating this issue and reducing the likelihood that users will avoid these passwords.
Furthermore, with the recent surge in popularity of coding agents and vibe-coding tools, people are increasingly developing software without looking at the code. We’ve seen that these coding agents are prone to using LLM-generated passwords without the developer’s knowledge or choice. When users don’t review the agent actions or the resulting source code, this “vibe-password-generation” is easy to miss.
TFA shows results obtained using several major LLMs, including GPT, Claude, and Gemini in their latest versions and most powerful variations, and found that all of them generate weak passwords.
Originally spotted on Schneier on Security.
(Score: 2) by VLM on Saturday February 28, @03:48PM (6 children)
That's why password managers that automate password generation don't use CSPRNGs they use the much simpler and faster "trust me bro" algorithm. Don't need to download the list of stored passwords if you know the algo to generate the "secretly" stored passwords is just SHA1(user name+site dns name) or similar.
After all, the people who don't trust Microsoft to store their passwords in plain text in notepad.exe will totally trust their password manager extension written and published by "Unknown LLC based in China" surely a much more trustworthy bunch. And don't call me surely, or Shirley.
(Score: 2) by JoeMerchant on Saturday February 28, @05:04PM (3 children)
I like TwoFish as an encryption algorithm - as secure as AES plus it's obscure.
Take your source material, TwoFish encrypt it, base64 encode that, add a ! at the end et voila! A secure looking deterministic password. Take your source material and append a sequence number and you've got rotating secure looking passwords - maybe even use ! as the "special character" for rotation 1, @ for rotation 2, # for rotation 3, etc. You can always reconstitute your password as long as you know the source phrase and sequence number.
🌻🌻🌻🌻 [google.com]
(Score: 2) by fliptop on Saturday February 28, @06:17PM
One fish two fish, red fish blue fish
I think my daughter used that one 25 years ago to lock her diary.
Ever had a belch so satisfying you have to blow your nose afterward?
(Score: 2) by VLM on Saturday February 28, @07:39PM (1 child)
Can, but you're basically making a hash function the hard way.
If you want to see some post-quantum crypto hash function drama, look at the battle over BLAKE vs Keccak for the SHA3 competition. BLAKE was going to win until the TLAs said "no" probably because they don't have a back door baked into the cake.
(Score: 2) by JoeMerchant on Saturday February 28, @07:48PM
I sincerely believe, if there was a backdoor baked into Keccak, we'd have heard about it by now. Too many academics out there contemplating the indentations on the surface of that body...
Really, none of this is hard stuff if you've got the libraries that implement it.
I have used SHA3 as a way to put a "passphrase" in source code, then boost its entropy for use in... whatever. So, your sourcecode says your passphrase is "holy.hamster.roller.bag" but the UTF-8 of that is SHA3'ed and that pile of white-noise bytes output by SHA3 is used as salt or whatever other quasi-random input you need to an algorithm.
🌻🌻🌻🌻 [google.com]
(Score: 2) by Ken_g6 on Saturday February 28, @06:49PM (1 child)
Actually, that seems like it should be fairly secure if salted with a secure master password. Just SHA1(master password+user name+site dns name). It should be at least as secure as constantly reusing the master password, anyway.
The downside is the resulting password is too long. It can be shortened with conversion to base64 or base85 encoding, but it would still have to be truncated in many cases.
(Score: 2) by VLM on Saturday February 28, @07:15PM
Still the attack surface is reduced from "the password could be any UTF-8 string" to all an attacker needs is the master key.
You could expect lots of corporate PR nonsense about they've never released decrypted passwords to anyone... although they'll give out master passwords upon request or search warrant which boils down to the same outcome.