frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

France's homegrown open source online office suite

https://github.com/suitenumerique
426•nar001•4h ago•201 comments

British drivers over 70 to face eye tests every three years

https://www.bbc.com/news/articles/c205nxy0p31o
132•bookofjoe•1h ago•106 comments

Start all of your commands with a comma (2009)

https://rhodesmill.org/brandon/2009/commands-with-comma/
437•theblazehen•2d ago•156 comments

Leisure Suit Larry's Al Lowe on model trains, funny deaths and Disney

https://spillhistorie.no/2026/02/06/interview-with-sierra-veteran-al-lowe/
26•thelok•1h ago•2 comments

Hoot: Scheme on WebAssembly

https://www.spritely.institute/hoot/
86•AlexeyBrin•5h ago•16 comments

OpenCiv3: Open-source, cross-platform reimagining of Civilization III

https://openciv3.org/
778•klaussilveira•19h ago•241 comments

Stories from 25 Years of Software Development

https://susam.net/twenty-five-years-of-computing.html
34•vinhnx•2h ago•4 comments

First Proof

https://arxiv.org/abs/2602.05192
38•samasblack•2h ago•23 comments

Reinforcement Learning from Human Feedback

https://arxiv.org/abs/2504.12501
54•onurkanbkrc•4h ago•3 comments

Software Factories and the Agentic Moment

https://factory.strongdm.ai/
17•mellosouls•2h ago•18 comments

The Waymo World Model

https://waymo.com/blog/2026/02/the-waymo-world-model-a-new-frontier-for-autonomous-driving-simula...
1027•xnx•1d ago•584 comments

Coding agents have replaced every framework I used

https://blog.alaindichiappari.dev/p/software-engineering-is-back
169•alainrk•4h ago•225 comments

Vocal Guide – belt sing without killing yourself

https://jesperordrup.github.io/vocal-guide/
167•jesperordrup•10h ago•61 comments

A Fresh Look at IBM 3270 Information Display System

https://www.rs-online.com/designspark/a-fresh-look-at-ibm-3270-information-display-system
24•rbanffy•4d ago•5 comments

StrongDM's AI team build serious software without even looking at the code

https://simonwillison.net/2026/Feb/7/software-factory/
16•simonw•2h ago•15 comments

Unseen Footage of Atari Battlezone Arcade Cabinet Production

https://arcadeblogger.com/2026/02/02/unseen-footage-of-atari-battlezone-cabinet-production/
103•videotopia•4d ago•27 comments

Vinklu Turns Forgotten Plot in Bucharest into Tiny Coffee Shop

https://design-milk.com/vinklu-turns-forgotten-plot-in-bucharest-into-tiny-coffee-shop/
5•surprisetalk•5d ago•0 comments

72M Points of Interest

https://tech.marksblogg.com/overture-places-pois.html
12•marklit•5d ago•0 comments

Show HN: Look Ma, No Linux: Shell, App Installer, Vi, Cc on ESP32-S3 / BreezyBox

https://github.com/valdanylchuk/breezydemo
265•isitcontent•20h ago•33 comments

Making geo joins faster with H3 indexes

https://floedb.ai/blog/how-we-made-geo-joins-400-faster-with-h3-indexes
152•matheusalmeida•2d ago•42 comments

Monty: A minimal, secure Python interpreter written in Rust for use by AI

https://github.com/pydantic/monty
277•dmpetrov•20h ago•147 comments

Ga68, a GNU Algol 68 Compiler

https://fosdem.org/2026/schedule/event/PEXRTN-ga68-intro/
35•matt_d•4d ago•10 comments

Hackers (1995) Animated Experience

https://hackers-1995.vercel.app/
546•todsacerdoti•1d ago•263 comments

Sheldon Brown's Bicycle Technical Info

https://www.sheldonbrown.com/
418•ostacke•1d ago•110 comments

What Is Ruliology?

https://writings.stephenwolfram.com/2026/01/what-is-ruliology/
65•helloplanets•4d ago•68 comments

Show HN: I spent 4 years building a UI design tool with only the features I use

https://vecti.com
364•vecti•22h ago•164 comments

Show HN: Kappal – CLI to Run Docker Compose YML on Kubernetes for Local Dev

https://github.com/sandys/kappal
16•sandGorgon•2d ago•4 comments

Show HN: If you lose your memory, how to regain access to your computer?

https://eljojo.github.io/rememory/
338•eljojo•22h ago•206 comments

An Update on Heroku

https://www.heroku.com/blog/an-update-on-heroku/
457•lstoll•1d ago•301 comments

Microsoft open-sources LiteBox, a security-focused library OS

https://github.com/microsoft/litebox
372•aktau•1d ago•195 comments
Open in hackernews

Why Bcrypt Can Be Unsafe for Password Hashing?

https://blog.enamya.me/posts/bcrypt-limitation
14•enamya•3mo ago

Comments

byhemechi•2mo ago
Does this really need yet another blog post? 72 characters is more than enough to be resistant to brute-force attacks, as demonstrated by thousands of data breaches containing bcrypt hashes that remain uncracked (excluding the obvious top 1k passwords/ credential stuffing). In my personal opinion calling it "unsafe" is just fear mongering, especially in conjunction with a recommendation of using Argon2 which is comparatively very new and is probably safe - but once again, does not have the proven record that bcrypt does.
mikehall314•2mo ago
I agree 72 characters is plenty for most circumstances. However, as the blog points out, this is a byte limit not a character limit.

Some of the family emoji can be > 20 bytes. Some of the profession emoji can be > 17 bytes. If people are using emoji in their passwords, we could quite quickly run out of bytes.

I think it’s a limitation worth being aware of, even if “unsafe” is perhaps overstating it.

testdelacc1•2mo ago
Does anyone actually use emoji as a password.
flysand7•2mo ago
yea, me (pls dont crack)
3eb7988a1663•2mo ago
You could ask for your password to be removed from the list: https://github.com/danielmiessler/SecLists/pull/155
embedding-shape•2mo ago
I never actually considered it until I read parent, and now I'm gonna try to start using it wherever it's supported, it's genius to use it for passwords as long as it's supported by the platform. Edit: Just to clarify, together with a password manager of course, otherwise I'd never have the patience for it.
byhemechi•2mo ago
I still don't see how that's an issue, yes a password using a series of ridiculously complicated family emoji will be truncated but the actual bytes still provide entropy, just because the data doesn't use pixels when rendered doesn't mean it doesn't increase the search space
anonym29•2mo ago
If your password is comprised of three emojis that each take up 24 bytes, then yes, a 72 byte truncation dramatically reduces the search space for a brute force against these hypothetical 24-byte-emoji-only passwords.

There are far fewer possible combinations of any three emojis than there are any 72 ASCII characters.

This is x^3 vs y^72, where X is the total number of distinct emojs and Y is the total number of distinct ASCII characters.

24 bytes of data is not 24 bytes of entropy if there are only a couple thousand different possible inputs to produce all of the possible 24 byte sequences produced by those inputs.

For simplicity: picture having only two possible input buttons. Each one produces 1000 bytes of random-looking data, but each one always produces the exact same 1000-byte sequence, respectively. You have a maximum password of 1 button press. The "password" may contain 1000 bytes, but you only have one bit of entropy, because the attacker doesn't need to correctly guess all 1000 bytes, they only need to correctly guess which of the two buttons you pressed.

Of course, in practice, not all emojis are 24 bytes, and I'd assume few people are using emoji-only passwords, but the distinction between bytes of data and bytes of entropy is worth clarifying, regardless.

arcfour•2mo ago
I would argue that a password containing emojis is unlikely to ever be cracked, because no attacker is going to test emojis unless they have some reason to believe you use them in your password.
anonym29•2mo ago
Attackers don't come up with every entry on the wordlist they throw into hashcat themselves. The attacker's imagination has essentially zero correlation with the contents of their wordlist.
arcfour•2mo ago
Okay. How many major wordlists include emojis?

Maybe...like...a dozen entries at most across all of them?

anonym29•2mo ago
Rest assured, the world's intelligence agencies and cybercrime rings aren't just taking vanilla open source wordlists off github and hoping they get lucky.

You don't know what your adversary's wordlist contains, and assuming you do is a recipe for overconfidence.

arcfour•2mo ago
Yes, "if your enemy is state sponsored attackers" you shouldn't do many things, like use bcrypt incorrectly, or really passwords almost at all. That's obviously not what I'm saying.
anonym29•2mo ago
Okay, use emojis in every password, you win, you're right, emojis make your password hack-proof to everyone who isn't the NSA.
arcfour•2mo ago
That is also not what I said either, but I admire your dedication to engaging in bad faith.
cwbriscoe•2mo ago
You could always pre-hash the password with sha256 or something similar to guarantee you won't go over the 72 byte limit.
stavros•2mo ago
I don't understand why this isn't a mandatory first step in the bcrypt algorithm itself. Who thought that a 72 byte limit was a good idea?
zetanor•2mo ago
The hash is 24 bytes. Even without an input character limit, you're likely to find tons of valid aliases for your 1000-character password within the 72-byte password space.
enamya•2mo ago
Well, if you limit the discussion to passwords, you're right, maybe no need to worry especially if using randomly generated ones (like ones from password managers), but if the algorithm is used to check some "composed" credentials (like what happened with Okta last year) then maybe it's worth worrying about, no ?
K0IN•2mo ago
I don't find this too concerning but libraries should document this and maybe even raise exceptions on data longer than 72 bytes, failing silently is the worst behaviour.
basilikum•2mo ago
bcrypt is from 1999.

It's really sad that the state of the art from 25 years ago is still ahead of common practice today and you can be lucky to find it in systems today. Most systems still use general purpose cryptography hash functions for password storage. Those are explicitly designed with designed goals that go exactly contrary to the goals of password storage. For general purpose cryptographic hash functions being fast and very low in resource consumption and requirements is a feature. That is the exact opposite of what you want for password hashing. You want something that is much slower to have a higher work factor for an attacker and requires a significant amount of memory with pseudo random access for computation so you cannot easily implement it cheaply in hardware and cannot trivially parallelize many operations on the same piece of hardware.

PBKDF2 wich simply runs the same general purpose hash function for multiple rounds on the salted password only helps with the work factor but fails in everything else. Yet it's considered an acceptable password hashing function and probably even above average security.

We should be well beyond the usage of password for authentication and only using public key based systems for remote authentication. Instead we're using an extremely poor authentication mechanism for humans – one which is a security anti feature and the root of a huge portion of all successful attacks – and we're not even at the point of securing its secrets with long outdated security from the last millennium.

Please just use argon2 or yescrypt or scrypt. They are actually made for password hashing and use modern cryptography not from the year when Matrix was released.

TZubiri•2mo ago
Alternate title:

"Why Python's bcrypt implementation is unsafe for Password Hashing"

enamya•2mo ago
*used to be unsafe just to note, other implementations have the same design (silent and truncate), I've recently found out that htpasswd from Apache HTTP server has the same silent behavior