1. 7

    Embrace, extend, and extinguish.

    1. 1

      Nice post Jeff.

      2^256 is about 10^77, which happens to be an estimate for the number of atoms in the universe.

      I really like your blog layout. Have you published the code?

      1. 1

        Thanks! It’s using this Hugo theme https://github.com/htr3n/hyde-hyde with some tiny modifications.

      1. 2

        These are probably the weakest arguments against Bitcoin I’ve seen. But the coolest bit about Bitcoin is that it is completely voluntary, so you do your thing, and we’ll do ours.

        Real arguments against Bitcoin are:

        And I’m sure there are others but literally none of the ones presented here are valid.

        1. 29

          These are probably the weakest arguments against Bitcoin I’ve seen.

          As it says, this is in response to one of the weakest arguments for Bitcoin I’ve seen. But one that keeps coming up.

          But the coolest bit about Bitcoin is that it is completely voluntary, so you do your thing, and we’ll do ours.

          When you’re using literally more electricity than entire countries, that’s a significant externality that is in fact everyone else’s business.

          1. 19

            I would also like to be able to upgrade my gaming PC’s GPU without spending what the entire machine cost.

            This is getting better though.

            1. 1

              For what it’s worth, Bitcoin mining doesn’t use GPUs and hasn’t for several years. GPUs are being used to mine Ethereum, Monero, etc. but not BItcoin or Bitcoin Cash.

            2. 0

              When you’re using literally more electricity than entire countries, that’s a significant externality that is in fact everyone else’s business

              And yet, still less electricity than… Christmas lights in the US or gold mining.


              1. 21

                When you reach for “Tu quoque” as your response to a criticism, then you’ve definitely run out of decent arguments.

            3. 13

              Bitcoin (and all blockchain based technology) is doomed to die as the price of energy goes up.

              It also accelerates the exaustion of many energy sources, pushing energy prices up faster for every other use.

              All blockchain based cryptocurrencies are scams, both as currencies and as long term investments.
              They are distributed, energy wasting, ponzi scheme.

              1. 2

                wouldn’t an increase in the cost of energy just make mining difficulty go down? then the network would just use less energy?

                1. 2

                  No, because if you reduce the mining difficulty, you decrease the chain safety.

                  Indeed the fact that the energy cost is higher than the average bitcoin revenue does not means that a well determined pool can’t pay for the difference by double spending.

                  1. 3

                    If energy cost doubles, a mix of two things will happen, as they do when the block reward halves:

                    1. Value goes up, as marginal supply decreases.
                    2. If the demand isn’t there, instead the difficulty falls as miners withdraw from the market.

                    Either way, the mining will happen at a price point where the mining cost (energy+capital) meets the block reward value. This cost is what secures the blockchain by making attacks costly.

                    1. 1

                      Either way, the mining will happen at a price point where the mining cost (energy+capital) meets the block reward value.

                      You forgot one word: average.

                      1. 2

                        It is implied. The sentence makes no sense without it.

                        1. 1

                          And don’t you see the huge security issue?

                2. 1

                  Much of the brains in the cryptocurrency scene appear to be in consensus that PoW is fundamentally flawed and this has been the case for years.

                  PoS has no such energy requirements. Peercoin (2012) was one of the first, Blackcoin, Decred, and many more serve as examples. Ethereum, #2 in “market cap”, is moving to PoS.

                  So to say “ [all blockchain based technology] is doomed to die as the price of energy goes up” is silly.

                  1. 1

                    Much of the brains in the cryptocurrency scene appear to be in consensus that PoW is fundamentally flawed and this has been the case for years.

                    Hum… are you saying that Bitcoin miners have no brain? :-D

                    I know that PoS, in theory, is more efficient.
                    The fun fact is that all implementation I’ve seen in the past were based on PoW based crypto currencies stakes. Is that changed?

                    As for Ethereum, I will be happy to see how they implement the PoS… when they will.

                    1. 2

                      Blackcoin had a tiny PoW bootstrap phase, maybe weeks worth and only a handful of computers. Since then, for years, it has been purely PoS. Ethereum’s goal is to follow Blackcoin’s example, an ICO, then PoW, and finally a PoS phase.

                      The single problem PoW once reasonably solved better than PoS was egalitarian issuance. With miner consolidation this is far from being the case.

                      IMHO, fair issuance is the single biggest problem facing cryptocurrency. It is the unsolved problem at large. Solving this issue would immediately change the entire industry.

                      1. 1

                        Well, proof of stake assumes that people care about the system.

                        It see the cryptocurrency in isolation.

                        An economist would object that a stake holder might get a lot by breaking the currency itself despite the loss in-currency.

                        There are many ways to gain value from a failure: eg buying surrogate goods for cheap and selling them after the competitor’s failure has increased their relative value.

                        Or by predicting the failure and then causing it, and selling consulting and books.

                        Or a stake holder might have a political reason to demage the people with a stake in the currency.

                        I’m afraid that the proof of stake is a naive solution to a misunderstood economical problem. But I’m not sure: I will surely give a look to Ethereum when it will be PoS based.

                  2. 0

                    doomed to die as the price of energy goes up.

                    Even the ones based on proof-of-share consensus mechanisms? How does that relate?

                    1. 3

                      Can you point to a working implementation so that I can give a look?

                      Last time I checked, the proof-of-share did not even worked as a proof-of-concept… but I’m happy to be corrected.

                      1. 2

                        Blackcoin is Proof of Stake. (I’ve not heard of “Proof of Share”).

                        Google returns 617,000 results for “pure pos coin”.

                        1. 1

                          Instructions to get on the Casper Testnet (in alpha) are here: https://hackmd.io/s/Hk6UiFU7z# . No need to bold your words to emphasize your beliefs.

                          1. 3

                            The emphasis was on the key requirement.

                            I’ve seen so many cryptocurrencies died few days after ICO, that I raised the bar to take a new one seriously: if it doesn’t have a stable user base exchanging real goods with it, it’s just another waste of time.

                            Also, note that I’m not against alternative coins. I’d really like to see a working and well designed alt coin.
                            And I like related experiments as GNU Teller.

                            I’m just against scams and people trying to fool other people.
                            For example, Casper Testnet is a PoS based on a PoW (as Etherum currently is).

                            So, let’s try again: do you have a working implementation of a proof of stake to suggest?

                            1. 1

                              It’s not live or open-source, so I’d understand if you’re still skeptical, but Algorand has simulated 500,000 users.

                              1. 1

                                Again I don’t seem to understand your anger. We’re on a tech site discussing tech issues. You seem to be getting emotional about something that’s orthogonal to this discussion. I don’t think that emotional exhorting is particularly conducive to discussion, especially for an informed audience.

                                And I don’t understand what you mean by working implementation. It seems like a testnet does not suffice. If your requirements are: widely popular, commonly traded coin with PoS, then congratulations you have built a set of requirements that are right now impossible to satisfy. If this is your requirement then you’re just invoking the trick question fallacy.

                                Nano is a fairly prominent example of Delegated Proof of Stake and follows a fundamentally very different model than Bitcoin with its UTXOs.

                                1. 3

                                  No anger, just a bit of irony. :-)

                                  By working implementation of a software currency I mean not just code and a few beta tester but a stable userbase that use the currency for real world trades.

                                  Actually that probably the minimal definition of “working implementation” for any currency, not just software ones.

                                  I could become a little lengthy about vaporware, marketing and scams, if I have to explain why an unused software is broken by definition.
                                  I develop an OS myself tha literally nobody use, and I would never sell it as a working implementation of anything.

                                  I will look to Nano and delegated proofs of stake (and I welcome any direct link to papers and code… really).

                                  But frankly, the sarcasm is due to a little disgust I feel for proponents of PoW/blockchain cryptocurrencies (to date, the only real ones I know working, despite broken as actual long term currency): I can understand non programmers that sell what they buy from programmers, but any competent programmer should just say “guys Bitcoin was an experiment, but it’s pretty evident that has been turned to a big ponzi scheme. Keep out of cryptocurrencies! Or you are going to loose your real money for nothing.”

                                  To me, programmers who don’t explain this are either incompetent enough to talk about something they do not understand, or are trying to profit from those other people, selling them their token (directly or indirectly).

                                  This does not means in any way that I don’t think a software currency can be built and work.

                                  But as an hacker, my ethics prevent me from using people’s ignorance against them, as does who sell them “the blockchain revolution”.

                              2. 2

                                The problem is that in the blockchain space, hypotheticals are pretty much worthless.

                                Casper I do respect, they’re putting a lot of work in! But, as I note literally in this article, they’re discovering yet more problems all the time. (The latest: the security flaws.)

                                PoS has been implemented in a ton of tiny altcoins nobody much cares about. Ethereum is a great big coin with hundreds of millions of dollars swilling around in it - this is a different enough use case that I think it needs to be regarded as a completely different thing.

                                The Ethereum PoS FAQ is a string of things they’ve tried that haven’t quite been good enough for this huge use case. I’ll continue to say that I’ll call it definitely achievable when it’s definitely achieved.

                        2. 4

                          ASICboost was fixed by segwit. Bitcoin isn’t subject to ASICboost anymore, but Bitcoin Cash is.

                          1. 2

                            Covert asicboost was fixed with segwit, overt is being used: https://mobile.twitter.com/slush_pool/status/977499667985518592

                        1. 4

                          The author continues to post contrarian articles about Bitcoin here on Lobste.rs. That’s fine, I personally don’t think Bitcoin is everything it’s cracked up to be, but his arguments are strangely weak and lack quantifiable substance. There are real problems with Bitcoin. Is the author afraid a more pragmatic approach might help that devil of Bitcoin? I dislike American football, but I don’t see how that justifies an argument, “it’s a fad like Sea Monkeys”.

                          My larger criticism is why is this being upvoted on Lobste.rs, a community with BSD advocates who created foundational cypherpunk technology like OpenSSH? If we are going to criticize Bitcoin, I would hope this community could do better. Or maybe Lobste.rs is too hipster for Bitcoin, thus the upvotes.

                          1. 11

                            My larger criticism is why is this being upvoted on Lobste.rs, a community with BSD advocates who created foundational cypherpunk technology like OpenSSH?

                            Perhaps it’s because BSD advocates don’t tend to shy away from criticism in the way most Silicon Valley techbros do. If David’s points have the potential to make for better cryptoeconomics, then that’s a good thing. Personally, I think an argument that because the Internet was a success, $crypto will be too is a ridiculously flawed argument. I think his counterpoints are fairly weak too, but the only disappointment I have is that he reverts to attacks on the technology’s failings rather than sticking to the argument.

                            To be fair, the failings he raises are also valid criticisms, but I think the technology point distracts from the core counterpoint about the Internet’s success == $crypto success. But opinions are like assholes, this is just mine.

                            1. 1

                              My point is that I have no problem with Bitcoin criticism, as it deserves a lot, but this article is just plain terrible.

                              David doesn’t have points, just weak regurgitations everyone that has been involved has heard since 2011 while making straw men. Even the first quote, Erik’s point is that just like the Internet, he believes that a few people understand cryptocurrency’s potential. These few are the entrepreneurs that will build the new systems into the future. It’s not “this was big so this will be too”. His point is, “brilliant minds built this, and this too is also attracting brilliant minds”.

                              Erik had done some brilliant work. He’s not the best subject for characterization into straw men.

                              Base on the volume of code, education, and interest in security and cryptography, Erik’s prediction has been 100% right.

                              1. 0

                                this is your asshole?

                                1. 2

                                  No, it’s my opinion, although the two may smell somewhat similar.

                              2. 7

                                “My larger criticism is why is this being upvoted on Lobste.rs, a community with BSD advocates who created foundational cypherpunk technology like OpenSSH?”

                                I don’t see the connection. Lobsters are more likely to be working on the kind of tech using the kind of currencies that Bitcoin says can’t get the job done or it can do it better. If anything, I’d expect more support of anti-Bitcoin articles from Lobsters given its failings. Whereas, some sites jump on any cool, hipster trend. They’d praise or defend it endlessly despite it’s problems. Maybe cite a 100 proposals or projects that should solve them which aren’t getting momentum but should happen any day now.

                                I think his write-up is good at least in that it addressed its main counter about the Internet. People seeing the Mother of all Demos would know exactly why doing things with computers over Internet might be profoundly better. Then each of the services they built on top of it solved a pressing need with some implementations spreading far and wide since users saw their value. In Bitcoin’s case, they’re creating something we don’t have an obvious need for that performs worse than our current systems on a lot of metrics users care about. So, it’s quite opposite of the Internet in both perceived and actual utility whether we’re talking initial introduction or where it is today.

                              1. 1

                                I should have looked at the clock before clicking.

                                1. 2

                                  Zamicol, I was going to suggest not using “satire” for Apr 1 submissions to make that a necessity. ;)

                                  1. 1

                                    You mean the calendar?

                                  1. 1

                                    Why not establish a JOSE subset with said “secure implementation” and give a name to your subset?

                                    JOSE is a broad standard providing a basic framework to do many things. At times it just provides guidelines (just look at rfc 7800). It’s not designed to be the end all “secure solution”. That’s simply not its stated design goals.

                                    JOSE assumes that specific applications will use a small subset a features for specific things. It’s assumed that the developer has some clue what they are doing. Based on the JOSE philosophy, I would assume that standard libraries for specific usages would be established which would in turn be used by end developers. The article doesn’t seem to consider this organization.

                                    As the larger industry moves to adopt JOSE for specific secure applications, why not build your solution on something JOSE like? https://xkcd.com/927/ The reason JOSE doesn’t use “ver” is because it’s assumed specific applications should have foreknowledge of a particular JOSE usage. The application would define “ver”. BUT there is no reason why you can’t fit your “ver” philosophy into JOSE. Moreover, JOSE is designed to accommodate this sort of extension. The article lead the read to conclude, “alg”:“none” is proof of JOSE’s fallacy. This is not the case. It is only proof of JOSE’s objectives.

                                    Now to change from criticism to commendation, I commend paseto’s continued use of json. https://github.com/paragonie/paseto/blob/master/docs/01-Protocol-Versions/Version2.md I’m glad to see it’s remarkable like JOSE, but that leads me to wonder could you really not figure out how to fit your philosophy in something considered by some great minds in the industry?

                                    1. 4

                                      The blog post explains why, dude. In security world, it’s bad practice to enable devs to do the wrong insecure thing.

                                      1. 2

                                        Why not establish a JOSE subset with said “secure implementation” and give a name to your subset?

                                        Secure cryptography is inherently incompatible with insecure cryptography, and since most of the vulnerabilities in cryptography protocols occurs at the joinery rather than the primitives, bolting a massive backward compatibility with JOSE would be self-defeating.

                                        The goal of Paseto is to be boring (PDF).

                                      1. 17

                                        If only json had allowed trailing commas in lists and maps.

                                        1. 9

                                          And /* comments! */

                                          1. 3

                                            And 0x... hex notation…

                                            1. 3

                                              Please no. If you want structured configs, use yaml. JSON is not supposed to contain junk, it’s a wire format.

                                              1. 4

                                                But YAML is an incredibly complex and truth be told, rather surprising format. Every time I get it, I convert it to JSON and go on with my life. The tooling and support for JSON is a lot better, I think YAMLs place is on the sidelines of history.

                                                1. 4

                                                  it’s a wire format

                                                  If it’s a wire format not designed to be easily read by humans, why use a textual representation instead of binary?

                                                  If it’s a wire format designed to be easily read by humans, why not add convenience for said humans?

                                                  1. 1

                                                    Things don’t have to be black and white, and they don’t even have to be specifically designed to be something. I can’t know what Douglas Crockford was thinking when he proposed JSON, but the fact is that since then it did become popular as a data interchange format. It means it was good enough and better than the alternatives at the time. And is still has its niche despite a wide choice of alternatives along the spectrum.

                                                    What I’m saying is that adding comments is not essential a sure-fire way to make it better. It’s a trade-off, with a glaring disadvantage of being backwards incompatible. Which warrants my “please no”.

                                                2. 1

                                                  http://hjson.org/ is handy for human-edited config files.

                                                  1. 1
                                                  2. 5

                                                    The solutions exist!


                                                    I don’t know why it’s not more popular, especially among go people.

                                                    There is also http://json-schema.org/

                                                    1. 3

                                                      I had to do a bunch of message validation in a node.js app a while ago. Although as Tim Bray says the spec’s pretty impenetrable and the various libraries inconsistent, once I’d got my head round JSON Schema and settled on ajv as a validator, it really helped out. Super easy to dynamically generate per message-type handler functions from the schema.

                                                      1. 2

                                                        One rather serious problem with json5 is its lack of unicode.

                                                      2. 3

                                                        I think this only show that JSON has chosen tradeoff that make it more geared to be edited by software, but has the advantage of being human editable/readable for debugging. JSON as config is not appropriate. There is so many more appropriate format (toml, yaml or even ini come to mind), why would you pick the one that doesn’t allows comments and nice sugar such as trailing commas or multiline string. I like how kubernetes does use YAML as its configuration files, but seems to work internally with JSON.

                                                        1. 8

                                                          IMO YAML is not human-friendly, being whitespace-sensitive. TOML isn’t great for nesting entries.

                                                          Sad that JSON made an effort to be human-friendly but missed that last 5% that everyone wants. Now we have a dozen JSON supersets which add varying levels of complexity on top.

                                                          1. 11

                                                            “anything whitespace sensitive is not human friendly” is a pretty dubious claim

                                                            1. 5

                                                              Solution: XML.

                                                              Not even being ironic here. It has everything you’d want.

                                                              1. 5

                                                                And a metric ton of stuff you do not want! (Not to mention…what humans find XML friendly?)

                                                                This endless cycle of reinvention of S-expressions with slightly different syntax depresses me. (And yeah, I did it too.)

                                                                1. -5


                                                                  1. 13

                                                                    Keep this shit off lobsters.

                                                          1. 2

                                                            Remember (the first?) bitcoin fork? On August 8th, 2010, ~184,467,440,737 bitcoins were created out of thin air. Bitcoin had to be forked to fix it.


                                                            1. 5

                                                              it is totally unrelated. bitcoin fork are related to weakness in the protocol, which have to be corrected to work as it should work. The problematic ethereum fork are here because the protocol work as it should work that is running program without human supervision

                                                            1. 3

                                                              Great comment on Hacker News about what happened:


                                                              1. 1

                                                                Here’s how I’ve used git to push to deploy in the past.


                                                                This then evolved to where I used git tags to determine deployment with something along the lines of this: https://github.com/zamicol/gitversion

                                                                1. 3

                                                                  I see a lot of what he talks about echoed in Effective Go.

                                                                  1. 5

                                                                    I can’t help but feel their resignation is a mistake.

                                                                    1. 34

                                                                      From my laypersons perspective, their resignation is a public recognition and declaration that the EFF no longer has confidence in the W3C’s ability to operate with the goals and bounds of its original mission.

                                                                      In that, if that is the case, I agree with the sentiment, and the EFF’s protest.

                                                                      1. 22

                                                                        Given how the disagreement has developed so far, it was the only thing for them left to do. Though quite tragical, in its most literal, classical sense, I agree.

                                                                        1. 4

                                                                          What do they achieve by resigning? What will they miss out on? I honestly don’t know enough to judge or feel much about this, but either way it looks like this is a bridge burnt in a demonstration of principles. Perhaps they garner upvotes and support – in principle. Does that give them more than they gained or could have gained from W3C membership in the future?

                                                                          1. [Comment removed by author]

                                                                            1. 5

                                                                              Quite right–as illustration of this, part of the reason this has succeeded was that Mozilla caved in an effort to preserve marketshare in the face of less ideologically-pure browsers. Their tacit approval of DRM emboldened the others to push it through, and now it can be pointed at in defense of the odious thing.

                                                                            2. 16

                                                                              Well, they only joined W3C to veto EME. The veto didn’t work, so what’s left for them to do?


                                                                              1. -3

                                                                                If you had joined a chess club, and then some way or another it turned out to be a rape club travelling the world raping random people. Should you resign? Or should you stay to ‘correct the course’?

                                                                                I mean, you do gain a lot from the membership of said rape club, namely the opportunity to rape random people.

                                                                                What would you achieve from resigning?

                                                                                1. 17

                                                                                  Could you make your point without the references to sexual violence next time? It’s neither necessary to making your point nor kind to those in your audience who might have been on the receiving end of similar, which is two out of the three strikes.

                                                                            3. 4


                                                                            1. 9

                                                                              Some argue that this could be not the only high-paying company with anti-tab guidelines: https://google.github.io/styleguide/cppguide.html#Spaces_vs._Tabs

                                                                              1. 5

                                                                                Google also made Go which uses tabs.

                                                                                Indentation We use tabs for indentation and gofmt emits them by default. Use spaces only if you must.

                                                                                1. 2

                                                                                  OK, this is totally personal preference here, but - this is another nail in Go’s coffin as far as I’m concerned.

                                                                                  It’s 2017. Why tabs? WHY? :)

                                                                              1. 2

                                                                                Will this help OpenBSD as well?

                                                                                1. 3

                                                                                  Originating from NetBSD, the *BSD wireless stacks have diverged quite a bit at this point, both in design and implementation. FreeBSD can certainly serve as a design reference for OpenBSD wireless code. Copying code is possible, too, but not verbatim because of several differences in the core wireless data structures. Porting wifi drivers between systems takes a bit of effort for the same reasons.

                                                                                1. 6

                                                                                  JWT != JOSE.

                                                                                  For reference:

                                                                                  JOSE RFC

                                                                                  Other RFC’s

                                                                                  EDIT: Looks like the authors are aware. They just changed the title from “JWT (JSON Web Tokens) is a Bad Standard That Everyone Should Avoid” to “JOSE (Javascript Object Signing and Encryption) is a Bad Standard That Everyone Should Avoid”

                                                                                  1. 39

                                                                                    Reprising and reformatting something I wrote on that other site about this:

                                                                                    The problem with JWT/JOSE is that it’s too complicated for what it does. It’s a meta-standard capturing basically all of cryptography which wasn’t written by or with cryptographers. Crypto vulnerabilities usually occur in the joinery of a protocol. JWT was written to maximize the amount of joinery.

                                                                                    Negotiation: Good modern crypto constructions don’t do complicated negotiation or algorithm selection. Look at Trevor Perrin’s Noise protocol, which is the transport for Signal. Noise is instantiated statically with specific algorithms. If you’re talking to a Chapoly Noise implementation, you cannot with a header convince it to switch to AES-GCM, let alone “alg:none”. The ability to negotiate different ciphers dynamically is an own-goal. The ability to negotiate to no crypto, or (almost worse) to inferior crypto, is disqualifying.

                                                                                    Defaults: A good security protocol has good defaults. But JWT doesn’t even get non-replayability right; it’s implicit, and there’s more than one way to do it.

                                                                                    Inband Signaling: Application data is mixed with metadata (any attribute not in the JOSE header is in the same namespace as the application’s data). Anything that can possibly go wrong, JWT wants to make sure will go wrong.

                                                                                    Complexity: It’s 2017 and they still managed to drag all of X.509 into the thing, and they indirect through URLs. Some day some serverside library will implement JWK URL indirection, and we’ll have managed to reconstitute an old inexplicably bad XML attack.

                                                                                    Needless Public Key: For that matter, something crypto people understand that I don’t think the JWT people do: public key crypto isn’t better than symmetric key crypto. It’s certainly not a good default: if you don’t absolutely need public key constructions, you shouldn’t use them. They’re multiplicatively more complex and dangerous than symmetric key constructions. But just in this thread someone pointed out a library — auth0’s — that apparently defaults to public key JWT. That’s because JWT practically begs you to find an excuse to use public key crypto.

                                                                                    These words occur in a JWT tutorial (I think, but am not sure, it’s auth0’s):

                                                                                    “For this reason encrypted JWTs are sometimes nested: an encrypted JWT serves as the container for a signed JWT. This way you get the benefits of both.”

                                                                                    There are implementations that default to compressing plaintext before encrypting.

                                                                                    There’s a reason crypto people table flip instead of writing detailed critiques of this protocol. It’s a bad protocol. You look at this and think, for what? To avoid the effort of encrypting a JSON blob with libsodium and base64ing the output? Burn it with fire.

                                                                                    1. 3

                                                                                      I have a related but somewhat OT question. In one of the articles linked to by the article [1], they say this:

                                                                                      32 bytes of entropy from /dev/urandom hashed with sha256 is sufficient for generating session identifiers.

                                                                                      What purpose does the hash serve here besides transforming the original random number into a different random number? Surely the only reason to use hashing in session ID generation is if there’s no good RNG available in which case one might do something like hash(IP, username, user_agent, server_secret) to generate a unique token? (And in the presence of server-side session storage there’d be no point to including the secret in the hash because its presence in the session table would prove its validity.)

                                                                                      [1] https://paragonie.com/blog/2015/04/fast-track-safe-and-secure-php-sessions

                                                                                      1. 2

                                                                                        Yeah, if urandom is actually good, then hashing it serves no real purpose. (In fact if you want to get mathematical, it can only decrease the randomness, but luckily by an absolutely negligible amount). Certain kinds of less-than-great randomness can be improved by hashing (as a form of whitening), but no good urandom deserves to be treated that way.

                                                                                        1. 2

                                                                                          The reason for that is PHP is weird. PHP hashes session entropy with MD5 by default. Setting it to SHA256 just minimizes the entropy reduction by this step. There is no “don’t hash, just use urandom” configuration directive possible (unless you’re rolling your own session management code, in which case, please just use random_bytes()).

                                                                                          This is no longer the case in PHP 7.1.0, but that blog post is nearly two years old.

                                                                                        2. 2

                                                                                          Thanks for that very thorough dissection of JWT. Are there web app frameworks/stacks that do have helpfully secure and well-engineered defaults that you’d recommend?

                                                                                          1. 1

                                                                                            The post itself offers a suggestion (at the bottom): use libsodium.

                                                                                            1. 1

                                                                                              The author refers to Fernet as a JWT alternative. https://github.com/fernet/spec/blob/master/Spec.md

                                                                                              However, Fernet is not nearly as comprehensive as JOSE and does not appear to be a suitable alternative.

                                                                                              1. 2

                                                                                                Hah, it seems the article changed a few times, and not just the title…

                                                                                          1. 1

                                                                                            I built a tiny lib for working with json configs and go’s flag lib: https://github.com/zamicol/jsonflags

                                                                                            1. 8

                                                                                              Are passwords ‘broken’ in general? I don’t see the need to fix them.

                                                                                              1. 9

                                                                                                Passwords are pretty insecure. Most people reuse them. Compromising their password in one place (eg. Neopets) will allow you to assume their identity on most other services (Google, Facebook, Amazon, maybe a bank).

                                                                                                1. 6

                                                                                                  Is it passwords that are insecure or the person behind the password? If you use a password manager that lets you generate strong and unique passwords then I don’t see an issue. Then if a site gets compromised you just need to regenerate a new password for that site and not worry about the others you may have used the old password on.

                                                                                                  At the end of the day, it comes down to making a conscious effort to be smart about how you maintain your online identities.

                                                                                                  1. 11

                                                                                                    From a policy perspective, there’s not much difference between “this cannot be used securely” and “this is not used securely”. The net result in either case is poor security, and bemoaning the fact that people don’t pick secure passwords doesn’t solve the problem.

                                                                                                    Obviously from a personal perspective, there’s a lot you can do to maximize the security of your passwords (starting with generating distinct long, random passwords for everything and keeping them in a password manager). But your good password practices don’t really matter to Google, or anybody else using those passwords to authenticate you.

                                                                                                    1. 6

                                                                                                      Many security issues will be closely linked in some way to people. If your security mechanisms can’t account for the soft exploits, it’s an insecure system.

                                                                                                      1. 3

                                                                                                        The problem is that most people don’t do this, and there’s only so much a site can do to encourage its users to do this. In the end, it can’t tell if your password is used elsewhere, or from a password manager, or anything else. What they can do is look for some method of authentication that avoids or augments the password, to (hopefully) provide a greater degree of security by default.

                                                                                                    2. 3

                                                                                                      Passwords are absolutely broken.

                                                                                                      LinkedIn was hacked 4 years ago, 164 million accounts compromised, and we just find this out in the past month?

                                                                                                      Https? There’s no way to ensure that it’s even set up properly. The DROWN attack and heartbleed are both great examples. https://thehackernews.com/2016/03/drown-attack-openssl-vulnerability.html

                                                                                                      Depending on any multi-use token for authentication should be considered poor security.

                                                                                                      1. 7

                                                                                                        Https? There’s no way to ensure that it’s even set up properly.

                                                                                                        I’m not sure what this has to do with passwords.

                                                                                                        1. 4

                                                                                                          They’re typically transmitted over HTTPS; doubly a problem if they’re reused.

                                                                                                          1. 5

                                                                                                            If this is a problem for passwords, isn’t it also a problem for biometric data sent to a backend?

                                                                                                            Edit: in fact, all biometric data is “reused”, so wouldn’t that be even worse because once someone captures whatever data your fingerprint is turned into they can use that with any system that uses the same type of data?

                                                                                                        2. [Comment removed by author]

                                                                                                          1. 2

                                                                                                            Korelogics analysis of the Linkedin hash dump shows some interesting issues with the use and generation of passwords.

                                                                                                            I’m not sure what the solution is - but for me passwords are part of the problem.

                                                                                                            1. 2

                                                                                                              Here’s the thing: You’d have a similar problem with storing biometric data. Biometrics are strictly equivalent to a reasonably strong password, from the server’s perspective.

                                                                                                              They’re quite different from the user’s perspective, but I’d argue that they’re a step backwards because they’re immutable.

                                                                                                          2. 2

                                                                                                            Wasn’t the hack acknowledged way back in 2012? The new thing you’re hearing about is that the hacked passwords are finally being used.

                                                                                                            1. 1

                                                                                                              Depending on any multi-use token for authentication should be considered poor security.

                                                                                                              What would you do instead, in the context of a web application needed to authenticate a user?

                                                                                                          1. 1

                                                                                                            Great write up!

                                                                                                            Does git have an equivalent to Fsmonitor?

                                                                                                            1. 1

                                                                                                              It looks like it’s being actively worked on: http://marc.info/?l=git&w=2&r=1&s=watchman&q=b

                                                                                                            1. 8

                                                                                                              Strange no one is discussing it more.

                                                                                                              I love the idea. I think it’s about time passwords die, one way or another.

                                                                                                              1. 3

                                                                                                                I wish I could say “Because it’s a solved problem? SSL client certificates have been around for ages.” but alas I know of only one public website that uses SSL client certificates for authentication. (And it’s an SSL CA)

                                                                                                                1. 2

                                                                                                                  Linked Data Server https://databox.me/ uses client certificates.