Ask HN: Review my startup: http://sparkwall.me - <AUTHOR>

Hi All,
Just released our private beta of Sparkwall and we would love to hear your feedback!
Sparkwall is a visual collaboration tool that helps remote dev and creative teams communicate by sharing designs in real time.  The app is built on node.js, socket.io and MongoDB using Amazon EC2 and S3 for hosting and storage.
Some of our features: - Upload files through drag-and-drop - Support for 300 different image formats - Write text and draw freely.  - 16000x9000px work space - Point with your mouse, and ppl can see it in real-time <-- I like this feature :)
 We are currently running on Firefox 4 and Chrome 8+ (Other browsers will be supported shortly)
Invitation Code: HACKERNEWS Sign up: http://sparkwall.me
Thanks
Johan Ekhager Co-founder / CTO
http://sparkwall.me <comment><AUTHOR> Link: <http://sparkwall.me>

</comment><comment><USER2> I recall something exactly like this on HN a few weeks ago, public with a unique URL for each wall, except it didn't have shared mouse pointers. What was that post?

<comment><AUTHOR> Interesting. Couldn't find any post of it. If someone remember the name or post, please reply here. Good to know about similar products. :)

<comment><USER2> Here it is:

<http://corkboard.me/Ix1gsxLPuz>

<http://news.ycombinator.com/item?id=2486982> <http://news.ycombinator.com/item?id=1962554>

<comment><AUTHOR> Oh, thanks alot! Will check it out.

</comment></comment></comment></comment><comment><USER3> Are you using node.js for the whole stack? Or is there a Rails app running alongside for doing user accounts, payments, the marketing site/landing page etc?

<comment><AUTHOR> It's all built on node.js. We used rails before to handle user accounts and static pages but realized we could make it all with node.js and MongoDB instead with some cool template language. :)

<comment><USER3> Are you using a library for the user stuff in mongo/node, if you don't mind me asking? I haven't found anything that seems better than devise/cancan.

<comment><AUTHOR> We've built a lot on our own. Maybe Senchalabs Connect can help you, otherwise check <https://github.com/joyent/node/wiki/modules>. Don't know if it's better than devise/cancan though.

<comment><USER4> Devise and Cancan are User Authentication middleware for Rails

Check out <https://github.com/ciaranj/connect-auth> I can't vouch for the effectiveness, but it seems to be under active development.

</comment></comment></comment></comment></comment><comment><USER5> I like it. Good MVP. I could see my ecommerce company using it.

What features are you planning on rolling out?

<comment><AUTHOR> Thanks! Just curious, how do you think you would use it? New features are coming, support for safari, IE9, iPad/iPhone and Android and then make current functionality smarter and better. We will also listen to users so they can say what they want us to focus on.

<comment><USER5> Our designers frequently mock up designs for new features / versions of the site. They then get email responses that say X,Y, and Z (multiple times from different people). Sometimes they get conflicting X-1 and X-2.

With this I could see them sharing the wall with everyone and then getting collaborative feedback from all of the stakeholders.

What features specifically are you implementing? I would like undo, redo, step backward, step forward, and a better way to manage text.

</comment></comment></comment><comment><USER6> An absolutely thumbs up for the idea behind. It looks so well executed on a beautiful refined layout. Success.

<comment><AUTHOR> Thanks for those warming words! :) Invite your friends/co-workers! And if you want to give more feedback, contact me at email@example.com. //Johan

</comment></comment><comment><USER7> Looks good. The creative team at our digital agency love it.

<comment><AUTHOR> Thanks! Would be great to hear their thoughts aswell, if you don't mind.

</comment></comment><comment><USER4> I'm curious if you were inspired by Jef Raskin and the ZUI

</comment><comment><USER8> i need an invite code to sign up could u send me please one : firstname.lastname@example.com

<comment><AUTHOR> You're invited!

</comment></comment><comment><USER9> amazing! Google docs watch out this is way cooler

<comment><AUTHOR> Thanks! :) Any other thoughts about the funtionality?</comment></comment>


Daigou, a novel e-commerce business model, is an intriguing Chinese export - <AUTHOR> http://sgentrepreneurs.com/2012/11/16/daigou-sites-becoming-popular/

<comment><USER2> I've already seen something similar with JList/JBox: <http://www.jbox.com/> (JList.com contains some NSFW content.)

JList and friends actually maintain products in stock stateside, I'm not aware that they order products on demand.</comment>


Show HN: Open Source JavaScript Chess Board - <AUTHOR> http://chessboardjs.com/examples

<comment><AUTHOR> Hi everyone :)

I just released this component at v0.1.0

Feedback welcome!</comment>


Ask HN: Are there any open source MBA curricula? - <AUTHOR> There are plenty of open source Computer Science curricula out there.
Are there any similar open source curricula for business / management folks - something akin to an MBA program? <comment><USER2> Not open source, but worth checking: The Personal MBA by Josh Kaufman. Will help you know what those $xx.xxx MBAs can teach you. I believe that's not an actual MBA substitute; but it's good to know if the content is for you before enrolling into an actual MBA.

<comment><AUTHOR> Looks decent. Thanks!

</comment></comment><comment><AUTHOR> I found two other useful resources (1) Open Source MBA ([http://www.opensourcemba.org](http://www.opensourcemba.org))

(2) No-Pay MBA ([https://www.nopaymba.com/curriculum](https://www.nopaymba.com/curriculum))</comment>


Ask HN: What's cool these days? - <AUTHOR>

I'm looking to build something new, and need a refresher on the exciting opportunities at the moment.  So... what's good now?
PHP sucks now right?  Did Python replace that?  And what about IOS?  Is there more opportunity there, or is Android "where it's at" these days?  What area is hot?  Is social gaming still cool, or are we doing other stuff now like B2B?  Are we building cross-platform, or are we perfecting down on one platform at a time?
In other words, what's cool these days? <comment><USER2> > I'm looking to build something new, and need a refresher on the exciting > opportunities at the moment. So... what's good now?

That depends. What are you trying to accomplish?

> PHP sucks now right? Did Python replace that? And what about IOS? Is there > more opportunity there, or is Android "where it's at" these days?

Same answer -- it depends on what your goals are. You just asked a question so general that it mixed platforms (Android, IOS) with languages (Python, PHP), so your inquiry is too general to be meaningfully answered.

> PHP sucks now right? Did Python replace that?

There's really no comparison -- PHP and Python address completely different purposes. It's like asking which is better -- a car or a typewriter.

> In other words, what's cool these days?

Technology isn't a fashion show. Well, anyway, it shouldn't be.

</comment><comment><USER3> I find that HN is usually a leading indicator of tech. Just keep note of which technologies keep appearing week after week, and that's what you should look into.

</comment><comment><USER4> [http://www.thoughtworks.com/radar](http://www.thoughtworks.com/radar)

This should help. Best of luck!</comment>


Your Worst Enemy is Your Own Resistance to Change - <AUTHOR> http://bootstrappingmybusiness.com/2013/your-worst-enemy-is-your-own-resistance-to-change/

<comment><USER2> I have the same problem with distractions. Usually I blame the book, "Don't want to read this anymore, must be a crap book". My two methods for trying to keep at it are:

1) The Pomodoro Technique

2) If possible bend the exercise to fit my specific goals

On another note (not specific to picking up clients) I found the book www.businessmodelgeneration.com to be really helpful in my business explorations.</comment>


Neoliberalism: the deep story that lies beneath Donald Trump's triumph - <AUTHOR> http://evonomics.com/ruthless-network-super-rich-ideologues-killed-choice-destroyed-peoples-faith-politics/ <comment><AUTHOR> I posted the original article - I am European, so for me the most interesting parts are not directly related to Trump's election, but to something that to me looks very strange, and it's happening a lot around me. Nominally: people who leaned towards Progressive/Democratic positions are being more and more attracted by populist movements, and have started rooting for Le Pen or UKIP. Something that no more than 10 years ago would have been absolutely unthinkable.

This article is interesting (IMHO) because it mentions, at least, how the neoliberism managed to co-opt political figures like Blair, Bill Clinton (and a bunch of my own in Italy, too) - and how these started pushing for less and less State in their plans.

<comment><USER2> I see it here in the Netherlands as well, one cause is that we had some referenda in which the majority vote (no against a European constitution (we got the Geneva convention), no against associating with Ukraine) was ignored. This is of course food for anti Europe sentiment. That and then the never ending stories of bureaucratic non sense like the monthly move of parliament from Brussels to Strasbourg.

[0] [http://www.telegraph.co.uk/news/worldnews/europe/10565686/Th...](http://www.telegraph.co.uk/news/worldnews/europe/10565686/The- farce-of-the-EU-travelling-circus.html)

<comment><AUTHOR> My current take on the Populist gains in the last few years (based on this and other articles from the same author): I believe that State (capital S) main function is to take care of the "average citizen".

And we are all "average" in a way or the other... i.e. I could be a good coder, painter, car salesman, whatever - but this does not guarantee I have perfect health, or above-average business savvy, or I am a good parent, or ready to use a foreign language and move abroad to look for work.

The neo-liberist idea is to cater only for "superheroes" (and the rest will adapt or perish)... so now more and more people try to back parties that claim (or pretend) to have the "average" interests as their main goal... populist, nationalistic, "social-right" movements.

And this is because the Left in general started aligning itself with the neo- liberist ideals and pushed "freedom" above everything else (this has surely complex causes, including the failure of Communism: European left parties had to shift their goals to something that was as far as possible from the decline of the Socialist/Communist ideals).

</comment></comment></comment><comment><USER3> That's one way of seeing it.

Another way is people tired of career politicians, with a big government and a yet bigger spending, who doesn't doubt bailing out big banks and big corporations.

Rioters and thought police doesn't help, either.

<comment><USER4> > people tired of career politicians

I've never understood this. Why would you want someone in office that doesn't know what they're doing? I get that people are tired of _out of touch_ politicians, but wealthy people being elected doesn't solve the problem, only worsen it.

<comment><USER3> Successful people can be successful politicians. It's true that Trump is no expert, but he has a team of experts. He doesn't know about STEM but he assembled a team of advisors which include Elon Musk and Peter Thiel. He thought torture works, but James Mattis (Sec of Defense) told him it was false, and he accepted it.

<comment><USER5> Musk resigned and his entire cabinet is objectively the least qualified set of people in American history. I fail to see how stacking all your positions with people fundamentally opposed to the missions of every agency is somehow seen as a team of experts.

<comment><USER6> 1\. When did Musk resign? Everything I can find says that he is still a member of the advisory board.

2\. "Objectively the least qualified" is not the same thing as "doesn't agree with Democrats about the agency's proper mission."

<comment><USER5> Yes, because Ben Carson is fully qualified, and people's only issue with him is that they disagree with his approach. Get a life.

<comment><USER6> So you 1) did not address the fact that you completely made up the talking point that Musk resigned from the advisory board, presumably hoping that nobody here would check, and 2) apparently assume that I agree with every single Trump cabinet pick because I refuse to get on board with declaring the whole thing an unmitigated disaster. To address your specific example, of course Carson is not qualified for HUD, although he would have arguably been qualified for HHS. But I imagine you would not have been thrilled with him being appointed for any position at all, because one of the world's foremost neurosurgeons is some kind of barely-literate nincompoop, right?

I normally don't respond to trolls, especially ones that invent alternative facts from whole cloth, but I'll make an exception for you. Feel special?

EDIT: after checking out the rest of your contributions to this site, it seems your standard approach is to state your opinions as proven facts, from your hilarious "Balloon Theory" of how blenders remove fiber from food, to your dumbfoundingly ahistorical slander that the Second Amendment was written specifically to appease slaveholding Southerners.

Please try to adjust your approach. You'll find a much more receptive audience here if you admit that some things are just your personal perspective.

</comment></comment></comment></comment></comment></comment></comment><comment><USER2> I find it strange that Ayn Rand is not mentioned, she seems to be at the birth of this as well. I still believe strongly in her philosophy, her philosophy is pure but it was corrupted by such things as lobbying.

The ruthlessness is the unethical part, not the free market part. Effort and skill have to be rewarded. But when you add lobbying to the mix, you can be rewarded without effort of skill or you can be punished even while you show effort and have skill but lack a strong relation with those currently in power (the deep state, for lack of a better term, I borrowed it from Zeitgeist (or weltschmerz (a dutch podcast)), a documentary worth watching although I think it goes a bit far near the end of part 2 (addendum).)

<comment><USER7> Even without lobbying and corruption, economies of scale favor larger corporations over smaller ones. This concentrates wealth, and power, into the hands of ever fewer people - unconstrained, the free market leads to feudalism.

<comment><USER2> Fast growing startups seem to prove you wrong, just like the fact that Linux concurred the Server market or that Microsoft and IBM lost a lot of market share to Apple which in turn lost market share to Google. I think these are examples of fair competition: A large company grows stale or is aware of a trend to late and someone else jumps into a market hole they missed. This is a natural stop for monopolies (ok, the ISP situation in the US is something else, I agree, the cost to enter that market is extreme and you don't "share the copper/fiber" with multiple companies as other countries do).

The lobbying problem however pertains to companies such as Bechtel, Halliburton (construction), Raytheon (weapons manufacturer) and Monsanto (Genetically engineered crops) and many other operating at a level known in "Confessions of an economic hitman" as the Corporatocracy. In general these are companies further removed from the voters, and politicians serve as their proxies in order to obtains funds to be an influential politician in the first place.

<comment><USER7> So you would be in favour of an otherwise free market, but with the government breaking up companies that grow too* big? I.e., you agree excessive concentration of money and power is harmful, and would be willing to compromise free market ideals to prevent it?

Also, just because -some- companies can outperform larger ones in some areas, does not mean greater size does not have significant advantages. There's a good reason there's no mom&pop car manufacturers.

*E.g. so big that consumers no longer have a meaningful choice, or so big that they start to benefit from monopoly pricing or price collusion, or are able to make use of anti-competitive practices, such as stores selling their own brands more prominently.

<comment><USER2> I'm not arguing for intervention at all. I arguing against lobbying. Lobbying makes a market non-free, you know, when voters have to save an investment bank that is too large to fail while said bank cost them their jobs and their house. Such things can only happen in a corrupt society. I'm not claiming to have the solution I'm merely claiming that we should decouple politics from the wealthy and recouple it with everybody else.

</comment></comment></comment></comment></comment><comment><USER8> s/Neoliberalism/Vote Rigging/ ???</comment>


It's time for fancy apartments to offer balconies for drone landings - <AUTHOR> https://www.wired.com/2016/08/time-fancy-apartments-offer-balconies-drone-landings/#slide-1 <comment><USER2> Kind of foreshadowed in 5th Element when the Chinese Junk restaurant is serving food to Corbin Dallas at the window in his apartment.

</comment><comment><AUTHOR> They illustrate it with a picture of a high rise tower. I always thought that in a world of flying cars, people wouldn't try to live in very dense city centers but rather would live in a spacious house with a garden far away as it only takes a 15 min commute to fly 50km at 200km/h. Flying cars pretty much eliminate traffic jams.</comment>


Things to Use Instead of JSON Web Tokens - <AUTHOR> https://kev.inburke.com/kevin/things-to-use-instead-of-jwt/ <comment><USER2> > The problem with JWT is the user gets to choose which algorithm to use.

Only if you completely bungle the implementation on the server-side. The 'none' 'algorithm' isn't supported by up-to-date JWT libraries with a good track record, and you should always limit the algorithms you'll allow on the server. So if you sign your tokens with a RSA-2048 key-pair, you would discard any token that isn't using that algorithm.

Of course if you are building an API that blindly accepts whatever it receives from a user agent you are bound to create a security gap — but that holds true for anything users send you though, not just JWTs. JSON Web Token is not that hard to grok, and it isn't a 'foot-gun' technology (just practice trigger discipline — i.e., read the documentation).

I'm a Java guy, so I'll limit my experience to the libraries available there, but of the four Java libraries available, three provide strict validation of the signing algorithm out of the box, and explicitly document this in their examples and documentation (I think the fourth does too, but I haven't tried that one myself).

JSON Web Token is a neat standard that has a lot of good parts that can reliably be used to create and process authentication tokens. So if you are still worried about developers getting it wrong, then instead of saying 'don't use JWT', why not promote a safe subset of the specification instead and promote that? Call it 'iron-jwt' or something. It beats rolling your own solution.

Or if you want to be particularly constructive and feel that developers are misusing this technology, write a sensible, short, to the point implementers guide for using JWT and spread the word.

<comment><USER3> > Only if you completely bungle the implementation on the server-side.

Which happens with regularity. This is exactly what led to the vulnerabilities mentioned in the article.

This is a bit like arguing against the claim that generating SQL queries by concatenating strings is unsafe. "Only if you completely bungle escaping the parameters", right? As it turns out, that's an extremely common mistake. It's easier to use a known-safe practice like parameterised queries than it is to rely on developers avoiding this pitfall each and every time they have to execute an SQL query.

Likewise with this. We know that negotiating the algorithm is subject to mistakes, and it offers no benefits. So instead of relying on developers avoiding this pitfall each time, let's avoid the pitfall altogether and get rid of negotiation.

There's a human aspect to security that's being missed here. Saying what boils down to "well developers shouldn't write insecure code" doesn't actually stop developers from writing insecure code. You can point the finger after the fact, but if you want to actually improve security, we need better standards than this.

<comment><USER2> > This is a bit like arguing against the claim that generating SQL queries by > concatenating strings is unsafe. "Only if you completely bungle escaping the > parameters", right?

No, you document how it should be done. Any major database layer using SQL provides parametrised SQL queries, and strongly suggests developers use that (usually in the quick start guide). You can still do your own concatenation, but aren't advised to.

The JWT libraries that are up-to-date and well-documented don't recommend blindly trusting the algorithm set in the header either, they recommend safe approaches such as configuring your whitelist and letting any unlisted algorithms fail. For example:

[https://github.com/auth0/java-jwt#verify-a- token](https://github.com/auth0/java-jwt#verify-a-token)

Only if you completely refuse to read even the basic 'getting started' documentation will you get to this kind of weird vulnerability. The issues with this part of the JWT standard have been addressed by the libraries, what remains is just a little bit of effort on the part of the developer — which may be expected from someone writing security critical code.

That is, don't blame the hammer for the shoddy carpentry.

> So instead of relying on developers avoiding this pitfall each time, let's > avoid the pitfall altogether and get rid of negotiation.

So write a concise pamphlet that can easily be shared with all of the JWT libraries in an issue/bug report. If there is a good argument for having to explicitly whitelist algorithms, they might welcome the suggestion.

Some libraries already do this mind!

<comment><USER4> I just documented how it should be done, in the article at the top of the page. The answer is "don't use JWT." Use specific tools for the thing you are actually trying to do, that have API's that are harder to mess up.

<comment><USER5> By that logic the answer is also "don't use SQL".

<comment><USER4> More like "Don't use SQL, if a thing adjacent to SQL exists that is better suited to a particular use case, doesn't have a history of poor implementations, and is harder for implementers and end users to screw up."

In this case:

\- crypto_auth, or HMAC-SHA256 by itself, for authentication

\- crypto_secretbox for symmetric encryption

\- crypto_box or TLS for public key encryption

<comment><USER6> Good JWT libraries essentially have a "box" and "unbox" function; the work required by the client needed to go behind the library's back here is on the same level as that needed to behind crypto_box's. Further, crypto_box works on a lower level than JWT encode/decode functions typically do, and would leave many concerns that JWTs handle _in the user 's hands_ for them to handle, alone. Having the user write their own code to handle those concerns is a terrible idea.

<comment><USER7> I'm with you on this. I've never thought of JWTs as a session storage mechanism; rather, I've always thought of them as a simpler (JSON-based) alternative to technologies like X.509 attribute certificates and SAML assertions. If you're creating a ticket / verifiable claim, there are a bunch of security considerations that JWT at least lays the groundwork for, and that NaCl secretbox doesn't appear to offer. Curious what OP thinks about putting things like payload canonicalization, subject/issuer/audience specification, and expiration entirely in the user's hands. I suppose its up to implementors to do appropriate validation, but at least JWT simplifies the conversation a bit.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Never read such nonsense masquerading as an authoritative piece of information.

Author clearly doesn't appreciate that the ultimate truth of any authentication scheme is you should not trust anything from the user. So what if you take away a clients ability to specify what algorithm a piece of data is signed or encrypted with - if you blindly just accept whatever a client did and proceed then you're always gonna find yourself vulnerable.

Intel didn't use JWT tokens or pass a client header - they just trusted what the client sent and landed themselves in the same mess. I make the point to illustrate that what _real_ security pros do is make sure basic checks like validating user input is done regardless of what specification or algorithm is involved.

<comment><USER4> These points are covered in the article, and the library I wrote makes it impossible to parse a token without performing verification with a secret key

<comment><USER8> Yes I read. However, you've failed to grasp a few things:

1\. The client should not get to 'choose' which algo it uses, it merely states what algo it did use. Emphasis should be on the server to verify that the client didn't do (or claim to do) something bad.

2\. What happens if in 5 years time the algo you've standardised on is suddenly comprisable? You've ripped out the mechanism that updated clients could theoretically use to signify that they're using a newer algorithm. Take for example Git and its recent SHA collision issue.

3\. By emphasising that 'clients should not get to choose', you're making the case that the choice is of itself a weakness it is not. The weakness is often in how inputs are processed (and far more often than any weakness in algorithms).

<comment><USER4> I point out numerous cases where the server made a mistake in verifying the algorithm specified by the client. This is the point of reducing the complexity of the interaction

If you are using JWT and someone breaks SHA2, you still have to worry about downgrade attacks. To evade downgrade attacks, you'll have to detect the protocol the client sends, and reject tokens that specify SHA2 or below. Or, roughly the same position you'd be in with one good algorithm: still in need of a backwards incompatible upgrade

<comment><USER9> This concern was always supposed to be handled by algorithm whitelists. The _intent_ was that services would consult a whitelist of algorithms before accepting a particular JWT.

The idea was certainly not that services blindly accept any token from every algorithm shipped in the library.

Your browser supports TLS 1.0, should you throw it out?

> If someone breaks SHA2...

JWT has a built-in mechanism for handling this: expirations.

<comment><USER4> There's no "better TLS" out there for shipping a tool that connects to millions of different servers. There are many better options than JWT.

Unlike JWT, hundreds of the world's best security engineers at various browser companies are working on mitigating the situation as well as possible.

<comment><USER9> Indeed, however, consider that servers can and do limit which TLS versions and cipher suites they accept.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I maintain a spreadsheet of the pros and cons of various authentication techniques - [https://docs.google.com/spreadsheets/d/1tAX5ZJzluilhoYKjra-u...](https://docs.google.com/spreadsheets/d/1tAX5ZJzluilhoYKjra- uHbMCZraaQkqIHl3RIQ8mVkM/edit#gid=0)

JWT is extremely useful when you want a one-time use token to pass a claim to another system. For example, employee portal generates a link for a user to check their available leaves in the HR system. Since the user is logged in to the employee portal, they shouldn't have to login to the HR system. JWT is great for this use case. But for general sessions management, there are better solutions.

<comment><USER11> The use case you mention is exactly the reason, why we have SAML2 and similar SSOs.

<comment><USER12> It appears to be much, much simpler to just integrate JWT into your system than deploy a SAML identity provider. I would love to see an easy to deploy decent SML IdP, but so far I have not found one. If anyone has any recommendations I would love to hear them.

<comment><USER13> They dont exist! IMHO ADFS is actually the best of a bad lot. Your friendly Windows Admin can setup the SSO in a matter of minutes without having to know the spec inside out and upside down.

The other platforms I've used or integrated with - Tivoli, Layer 7, Ping Federate, a huge hack job written in PHP - all took weeks/months to get working.

That said I haven't tried Spring SAML recently, so maybe that is painless now. But probably not

</comment></comment></comment></comment><comment><USER14> There's a lot of conversation on when should I use JWTs and when not to.

But as alternatives go, has anyone tried using Macaroons?

They've been mentioned in HN a few times but I've never seen the tech catch up, even though it looks like a very cool way to implement authorization.

Is there any particular reason why?

Here are some resources I've found and I think Macaroons is a very interesting concept. Even the paper is accessible to someone like me, without any real security or cryptography expertise.

Research paper: [https://research.google.com/pubs/pub41892.html](https://research.google.com/pubs/pub41892.html)

A new way to do authorization: [http://hackingdistributed.com/2014/05/21/my- first-macaroon/](http://hackingdistributed.com/2014/05/21/my-first-macaroon/)

(This link has an invalid HTTPS certificate if that concerns you): [https://evancordell.com/2015/09/27/macaroons-101-contextual-...](https://evancordell.com/2015/09/27/macaroons-101-contextual- confinement.html)

After I found this, I've always wanted to try it out but haven't had the chance. Does anyone has any experience or comments about it?

<comment><USER15> You can use the http version until I get some time to setup letsencrypt (feel free to disable javascript/css/etc).

I've used macaroons in several settings and highly recommend them. The only thing really missing for "wider" adoption is something like a standard caveat language, the lack of which keeps macaroon use pretty localized to your specific deployment.

<comment><USER14> Thanks for the input!

I'm still hoping the tech catches up somehow and then there's probably going to be more people interested in a standardized way to define a caveat.

When I was toying with Macaroons some time ago, I thought that I could use JSON to format the caveat and toyed with the idea of defining a set of useful caveats, but never got too far.

<comment><USER15> It seems that most people have those thoughts when they play around with Macaroons :) Check out the google group for some discussions: [https://groups.google.com/forum/#!forum/macaroons](https://groups.google.com/forum/#!forum/macaroons)

If it wouldn't doom them to obscurity, I'd personally like to see a set of vocabularies that macaroon users can use (a la semantic web). This is probably as simple as namespacing caveats with globally unique identifiers to indicate the vocabulary.

<comment><USER14> Yes, exactly! I actually did read the whole forum when I found out about them, and that's where I got the idea actually. Not that I went much further than what was discussed, but it definitely planted a seed on my mind...

Re: Vocabulary

Something like that sounds reasonable. I would just maybe add some sort of SET operations logic that you could use to build more complex stuff.

Thus I would be able to delegate to someone a Macaroon that has admin access to all of Project P EXCEPT (or MINUS) access to Project P's children in list L. Or maybe delegate with access to any object in List (L1 AND L2). Sort of like a SQL query (to an extent).

At least that was the use case I needed back then, i.e. How to secure an API in a hierarchical way, such that certain user roles can access only certain children of a certain parent node.

</comment></comment></comment></comment></comment><comment><USER16> Almost all of the 'alternative' use cases mentioned by the OP are not what JWT was designed for. JWT was designed to authenticate users/entities by giving them a token which contains basic non-sensitive metadata about that user/entity. It's for authentication not for authorization.

Sure, some implementations of JWT have had bugs in the past, but this hasn't been an issue for quite a while and it's definitely not an issue with the RFC itself. It's the same as if you blamed the TLS/SSL RFC for being responsible for the heartbleed bug in OpenSSL - It makes no sense.

>> You might have heard that you shouldn't be using JWT. That advice is correct - you really shouldn't use it.

This type of blanket thinking is dangerous. There are cases where JWTs are practically necessary and unavoidable. Whenever an extremist blanket idea like this catches on in this industry, it becomes a major pain to have to explain to people over and over why in THIS SPECIFIC CASE it is actually the best solution possible.

<comment><USER17> > It's the same as if you blamed the TLS/SSL RFC for being responsible for the > heartbleed bug in OpenSSL - It makes no sense.

It makes _some_ sense.

Features are attack surface. Each extra feature or option your protocol enables is more code you need to manage. So careful decisions need to be made: just because you can easily specify a feature for many use-cases in your protocol doesn't mean you _should_ , because once you spec it people might just use it.

For heartbleed, for example, why was the TLS Heartbeat extension ever specified for TLS over reliable protocols? It serves no purpose: TCP has TCP_KEEPALIVE if that's a thing you need. But it _was_ specified, and because it was specified it was implemented, and then it became attack surface that needed to be protected. It wasn't. So I guarantee to you that if RFC 6520 had been more restricted in scope, the Heartbleed attack would not have happened (or would have been a much more minor story, I can't remember if Heartbleed affected only the TLS and not the DTLS implementation).

</comment></comment><comment><USER18> I disagree with most of his points, but what really bothers me is the underlying message of his article. I don't think we should fool ourselves into thinking we can design a protocol that isn't susceptible to implementation problems.

Did we get SSL/TLS right? No, we've failed a few times, but we're doing better. Why is that? People are paying attention more that ever to OpenSSL and now we have competition with LibreSSL and the like.

Side note: The irony of his coupler example; it's a flawed spec, not flawed implementations... the implementations followed the spec but the spec was dangerous from the start. JWT is the opposite: good spec, but a long time ago some early adopters didn't get things right.

<comment><USER19> I guess heartbleed gave everybody the wrong image, but most TLS vulnerabilities were vulnerabilities _in the spec_. The fixes to RC4, BEAST, SWEET32, POODLE, LOGJAM, CRIME, BREACH, BRICK, BORKED, BUSTED and whatever else you could think of - all involved changing the spec. Sometimes by adding mitigations, but mostly by banning TLS features.

TLS is a legacy protocol. Nobody likes it very much, but it's such an established standard that you don't have much choice than trying to fix it. The same might happen to JWT, but in both cases we'll be fixing the specs, not just the implementations.

<comment><USER20> You could look at SMACK TLS as a few dozen examples of implementation specific features due solely to the complexity of representing TLS state machines. These aren't protocol weaknesses, they're weaknesses in the implementation due to complexities in the protocol.

</comment></comment></comment><comment><USER21> I've implemented some of OpenID Connect, "a simple identity layer on top of the OAuth 2.0 protocol". Combined with OAuth 2.0, it's one of those giant corporate specs (giant at least for security/crypto purposes) with way too many options so anybody can do anything with any algorithm and any kind of workflow.

I wanted to go with a simple, minimal NaCl-based system but in the end did implement a lot of OpenID Connect in the hope it would make interoperability easier with existing client libraries. I don't want to write a client for each and every programming language other people in any related projects would want to use. That in my opinion is the value of something like JWT: you can tell people up front that that's the way they're going to get the user's ID data, no matter how much server or client implementations will be switched around.

I feel that when faced with a spec like OpenID Connect and OAuth 2.0, it's not necessary to implement more than what is strictly needed. If you don't need all the flows and algorithms in your project, don't implement and don't accept them. The parts you implement should comply – why base it on a spec if you throw any interoperability out of the window – but don't waste months of trying to correctly implement all of a huge corporate spec if that doesn't make sense for the size of your project or organisation. Complete implementations might have value only if that's your main product and you need that line to sell it.

I use JWT only as ID, not as session, allow only one server-chosen algorithm for signing, and rely on TLS for encryption.

There's clearly a need for up-to-date "web-approved" standards to pass crypto- friendly data structures around – or maybe I'm just not familiar with any recent efforts. Normalising and serialising JSON is pretty error prone...

</comment><comment><USER22> > implementation errors should lower your opinion of a specification. An error > in one implementation means other implementations are more likely to contain > the same or different errors. It implies that it's more difficult to > correctly implement the spec.

Discussion on cryptography and particular implementations aside, I think this is sound and I normally follow this when judging technologies.

</comment><comment><USER23> In cryptography, we have a concept of "misuse resistance". Misuse-resistant cryptography is designed to make implementation failures harder, in recognition of the fact that almost all cryptographic attacks, even the most sophisticated of them, are caused by implementation flaws and not fundamental breaks in crypto primitives. A good example of misuse-resistant cryptography is NMR, nonce-misuse resistance, such as SIV or AEZ. Misuse-resistant crypto is superior to crypto that isn't. For instance, a measure of misuse-resistance is a large part of why cryptographers generally prefer Curve25519 over NIST P-256.

So, as someone who does some work in crypto engineering, arguments about JWT being problematic only if implementations are "bungled" or developers are "incompetent" are sort of an obvious "tell" that the people behind those arguments aren't really crypto people. In crypto, this debate is over.

I know a lot of crypto people who do not like JWT. I don't know one who does. Here are some general JWT concerns:

* It's kitchen-sink complicated and designed without a single clear use case. The track record of cryptosystems with this property is very poor. Resilient cryptosystems tend to be simple and optimized for a specific use case.

* It's designed by a committee and, as far as anyone I know can tell, that committee doesn't include any serious cryptographers. I joked about this on Twitter after the last JWT disaster, saying that JWT's support for static-ephemeral P-curve ECDH was the cryptographic engineering equivalent of a "kick me" sign on the standard. You could look at JWT, see that it supported both RSA and P-curve ECDH, and immediately conclude that crypto experts hadn't had a guiding hand in the standard.

* Flaws in crypto protocols aren't exclusive to, but tend to occur mostly in, the joinery of the protocol. So crypto protocol designers are moving away from algorithm and "cipher suite" negotiation towards other mechanisms. Trevor Perrin's Noise framework is a great example: rather than negotiating, it defines a family of protocols and applications can adopt one or the other without committing themselves to supporting different ones dynamically. Not only does JWT do a form of negotiation, but it actually allows implementations to negotiate NO cryptography. That's a disqualifying own-goal.

* JWT's defaults are incoherent. For instance: non-replayability, one of the most basic questions to answer about a cryptographic token, is optional. Someone downthread made a weird comparison between JWT and Nacl (weird because Nacl is a library of primitives, not a protocol) based on forward-security. But for a token, replayability is a much more urgent concern.

* The protocol mixes metadata and application data in two different bag-of-attributes structures and generally does its best to maximize all the concerns you'd have doing cryptography with a format as malleable as JSON. Seemingly the only reason it does that is because it's "layered" on JOSE, leaving the impression that making a pretty lego diagram is more important to its designers than coming up with a simple, secure standard.

* It's 2017 and the standard still includes X.509, via JWK, which also includes indirected key lookups.

* The standard supports, and some implementations even default to, compressed plaintext. It feels like 2012 never happened for this project.

For almost every use I've seen in the real world, JWT is drastic overkill; often it's just an gussied-up means of expressing a trivial bearer token, the kind that could be expressed securely with virtually no risk of implementation flaws simply by hexifying 20 bytes of urandom. For the rare instances that actually benefit from public key cryptography, JWT makes a hard task even harder. I don't believe anyone is ever better off using JWT. Avoid it.

<comment><USER9> > For almost every use I've seen in the real world, JWT is drastic overkill; > often it's just an gussied-up means of expressing a trivial bearer token.

This is certainly true for schemes that require trips to a source-of-truth database to authorize a token (c->auth, c->resource, resource->auth). It's also true for schemes where the token is associated with capabilities that are loaded from a database. Using JWT to implement RBAC is flawed.

However, there is a strong use case for the token carrying its own capabilities -- that is, a token that is more than just "20 bytes of urandom".

If a resource service can derive the capabilities associated with a token generated by a trusted authentication service without contacting that service, that has real world implications for lower latency, higher throughput applications that are simpler to compose and operate.

As far the cryptographic credibility, the idea behind capability-based security is an old one, and I'm sure you're aware of the research. This particular spec may be problematic, folks may be misunderstanding and misusing the primitives, but the underlying idea is sound.

Previous HN discussion of CapSec Wikipedia article [https://news.ycombinator.com/item?id=10684129](https://news.ycombinator.com/item?id=10684129)

Google Fuscia [https://en.wikipedia.org/wiki/Google_Fuchsia](https://en.wikipedia.org/wiki/Google_Fuchsia)

<comment><USER23> I don't deny that capability tokens are useful; they certainly can be. JOSE is just a poor vector for getting them.

The issue isn't with capabilities, or delegated authentication, or public key tokens, or even standardizing any of those things. I think at this point I've been pretty clear about what I believe the issues actually are.

<comment><USER9> Thanks for clarifying; I'll reread your comments.

Do you have a standard that you would recommend for any of those things?

<comment><USER4> found in the article linked at the top of the page:

\- crypto_auth, or HMAC-SHA256 by itself, for authentication

\- crypto_secretbox for symmetric encryption

\- crypto_box or TLS for public key encryption

<comment><USER9> I was asking about standards for Web-based capabilities, delegated authentication, and public key tokens; not the individual message authentication or (a)symmetric encryption components.

Echoing tptacek's comment above: the problems with using those individual pieces is in the joinery - combining them in ways that are broken.

</comment></comment></comment></comment></comment></comment><comment><USER24> This complains that JWT does not have forward secrecy, and then recommends NaCl's box primitive instead... which does not have forward secrecy either. (This isn't exactly drawn attention to in the NaCl docs for some reason.)

</comment><comment><USER25> I am using JWT for my projects to keep stateless sessions between servers and for some other tokens (refresh, register, reset pass etc.). Of course extra security measures are required (MitM protection [HTTPS etc.], XSS / CSFR prevention etc.), but this has nothing to do with JWT. I use encryption with a frequently rotated private key to encrypt the part of the payload that only the server may read.

A good read at: [https://stormpath.com/blog/where-to-store-your-jwts- cookies-...](https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs- html5-web-storage)

<comment><USER19> The problems with JWT are not related to MITM, XSS or CSRF vulnerabilities. You'll have to address these issues regardless of the type of token you're using.

The problems with JWT can be divided into two classes: 1\. Too many options, making it easy to misuse. Even if you disallow the 'none' algorithm (like most newer JWT libraries), there are still many other ways to break it. e.g.: [https://auth0.com/blog/critical-vulnerabilities-in-json- web-...](https://auth0.com/blog/critical-vulnerabilities-in-json-web-token- libraries/)

2\. Misguided cipher choice. AES-GCM (easy target for nonce-reuse), RSA, NIST P-curves.

So in short, even if you're using encryption, JWT just makes it easy for the crypto itself to fail.

<comment><USER25> I agree. Thank you for pointing that out. That is why I restricted my JWT code to only accept / use certain options. Of course I could still have chosen the wrong cipher for my specific use case and am aware that JWT will not solve this for me.

What JWT is doing is actually not that special as it is just a standardized container (akin to MKV and supported codecs) inside which existing technologies can be used. Easy to write something similar if you know what you are doing. I did that before, but still missed some extra verifications already build into JWT.

Of course, the chosen technologies allowed to be used inside a JWT can still be prone to vulnerabilities. I am not sure if that can be blamed on JWT. People should still think about which options to use.

</comment></comment></comment><comment><USER26> This is a case where the high-level point - "insecure options shouldn't be configurable" \- conflicts with a reality of crypto protocols: you have to make tradeoffs based on the best known attacks and the platform you're running on, and those change over time. The best hashing algorithm, HMAC algorithm, and signing algorithm to use on a mobile device in 2007 isn't the same as the ones you'd pick today. Any protocol expected to last 10 years should allow for the selection of an underlying crypto algorithm. Maybe "none" should never have been an option - but tying the algorithm to the protocol has pretty severe drawbacks, too.

More broadly - JWT isn't just about the exchange between a single client and a server; the choice of "use cases" misses a very real constraint of multi-party protocols. Within the context of OpenID (or OAuth more broadly), it's about the relationship between an end-user, a resource owner, a client and an authorization server -- all of whom need to be able to interact with a token, and often offline.

<comment><USER23> This is in fact not true: an HMAC-based design from 2007, even one that used SHA-1, would remain sound today. HMAC hasn't changed in something like 20 years, and works even with MD5 (we've had since the 90s to make the migration from MD5 and I obviously don't recommend anyone continue using it).

To non-cryptographers, this idea that protocols need to be constantly ready to accept new ciphers in case there's a break in one of the old ones is a very big deal, so much so that every amateur crypto protocol design includes cipher suite negotiation as the centerpiece of the protocol. In reality, it's a minor concern. Which the exception of RC4, pretty much every TLS ciphersuite flaw has been the product of flawed joinery and not problems with underlying ciphers --- which is why the major breaches have forced us to move people not from one ciphersuite to another, but instead from SSL3 to TLS 1.0 to TLS 1.1.

For an expert design example, look at Trevor Perrin's Noise framework. An even simpler idea: simply specify a single set of coherent cryptographic constructions, and then version the whole protocol --- if there's a serious break in your protocol, you'll almost certainly have to make changes across the protocol anyways --- and upgrade the whole thing.

</comment></comment><comment><USER27> I was just thinking. What is a good way to phrase the problem in order to understand whether there are more pros / cons to having the client vs server decide which algorithms to use in a transaction.

I haven't thought this through fully, but as far as I can tell ecosystems on the web evolve. And so I think it's probably a good idea that we architect things for the web in such a way that we don't inhibit that evolution. When you put a decision like encryption algorithm in the client's hands does it feel to anyone else that the security will evolve more rapidly, and thus remain more robust? When the client is deciding, there's a larger pool of people "voting" for what is an acceptable level of security. Even though a lot of those "votes" will be based on the default settings of a library, that library will over time become less popular as more and more people consider it unsafe.

By the same token, if a particular service (server-side) does not keep up with that evolution, fewer and fewer people will use it as other (safer) services pop up.

</comment><comment><USER28> It doesn't seem like the author is actually proposing an alternative, rather, the only thing says is "Don't use JWT, here is how you can do X with Nacl"

Even worse;

It is suggested that to authenticate a user one should use TLS. That might be true for a login form, but not beyond that. Once you have logged the user in, you need to continue authentication on every request. JWTs are one way to put this information on the client side without having to put any much trust into it.

The second example is a simple asymmetric encryption example which... for some reason JWT is not a solution for? I've used Ed25519 plenty of times with JWT (custom algo header in this case), so I see no problem there plus... I don't think this is what JWT is actually trying to solve.

The third example is encrypted data to the client, which is also something JWT isn't trying to solve, this is what JWE is for. JWT is purposefully unencrypted and I'm not sure how many developers would actually pretend a signature is encryption.

The last part is an actual example of JWT use cases, in which case however the author blabs on about the (in)famous "algo=none" bug a lot of libraries had. I've specifically used the Go library mentioned and strictly enforcing the algo is a nonbrainer if you are using a custom one anyway. On the other hand, I still use HMAC for a seperate token for short-term authentication over endpoints (to make blacklisting logins easier).

So JWT simply gives me some flexibility in sharing common code for authentication, the same code can consume the long-term tokens and the short- term tokens and much more if needed in the future.

I'm not saying JWT is the end all for problems, but it's rather easy ready-to- use solution for some of my problems.

Why write a signature library when there is one ready to use that, with care, is safe to use?

<comment><USER4> I address these points in the article

</comment></comment><comment><USER29> "..."algorithm agility" that is a _proud_ part of the specification" (italics mine)

No idea about "JWT" but maybe this is part of the psychology that keeps schemes like SSL/TLS in use. (Part.)

Do you think there are people who are actually _proud_ of achieving complexity in a specification or implementation?

</comment><comment><USER6> > _But the server and the client should support only a single algorithm, > probably HMAC with SHA-256, and reject all of the others._

If you have a centralized system dealing w/ authentication, this doesn't work, as now everything that needs to verify JWTs needs the secret. The support for RSA, instead of HMAC, is there to meet a different set of requirement.

What people fail to remember is that JWTs — and the libraries that work w/ them — do not just wrap data to be authenticated. They also handle verifying the various claims on a token — is this token applicable here? is this token expired? — things relevant to an authentication token, not just a mere signed blob of data. The suggestion to leave those to be reimplemented by every single end-user is bad advice.

<comment><USER4> Maybe not a great time to mention I also found errors in the claims verification in the one library I tested, and ended up ripping that code out as well

</comment></comment><comment><USER30> What makes this all worse is that companies like Auth0 and Stormpath have flooded search results with self promoting blog posts masked as tutorials. This just makes it harder for developers to learn the basics without getting product shoved in their face.

<comment><USER31> I don't see a problem with companies writing tutorials and OSS libraries to share with the community. If there is an economic incentive for documentation to be written and free software to be created then what's the problem really?

If the article is blatant self-promotion then I could see the problem with that and those articles don't get anywhere on HN/Reddit/etc so they won't rank well on Google either. But I've seen some high quality docs/libraries coming out of companies like that and it's a great thing.

The aren't responsible for developers doing poor implementations of JWT. And other developers equally have a voice such as the OP if they have a problem with the choice of technology they are promoting.

</comment></comment><comment><USER32> For the record, JWT is a payload and format spec for JWS/JOSE, which is really what you're complaining about. JWT is merely a claims set and an optional dot- notation serialization of a single signature.

JWT/JWS libraries that handle all the validation alone are treacherous. You should ALWAYS parse the JSON before hand, perform your claims and header(s) validation, and then pass the payload/header/signature. If anything, it's computationally less risky than running the signature blindly through a signature validation function and then checking the header.

<comment><USER4> you could also choose to use safer libraries and cryptographic primitives

<comment><USER32> There's nothing a library can add to make things "safer" when it comes to application-specific constraints. If I'm checking to make sure I only accept a specific algorithm, I'm not going to blame a crypto library for validating something that is technically accurate (short of maybe disabling the "none" algorithm by default). You should also be in possession of at least the public key beforehand, and rely on that for authentication, rather than anything in the claim.

</comment></comment></comment><comment><USER33> The implementations of JWT that I've mostly used... internal signing and validation only... the algorithm and public key are pretty much pinned down. If you do that, JWT is a pretty valid format... it's when you leave things open to "whatever" that the security issues come through.

I don't have a problem with JWT, only in that having the signature method, etc configurable in the first place as an implementation detail is probably a bad idea.

</comment><comment><USER27> If the specification requires the server to decide which algorithm to use a naive client, who doesn't know which algorithms are safe or not, is just as dangerous.

As far as I know there are no algorithms that exist today that we can guarantee will never be broken in the future. So algorithm choice inherently must be decoupled from the specification.

EDIT: Or a naive server implementation for that matter...

</comment><comment><USER34> Are there any examples of big JWT hacks which took place due to a vulnerability

</comment><comment><USER19> Good writeup of what you should be careful with with regards to JWT. There are some inaccuracies there too. First of all, JWT doesn't support encryption at all - it's JWE that does that. It's an important distinction, since most JWT libraries I ran into don't feature encryption, so if you want encrypted tokens you'll need to use an extra JWE library, or a more full-featured JOSE library.

JWE also support more than just RSA - it definitely does support Elliptic Curve Cryptography (although I would prefer if they chose Curve25519 instead of the NIST curves), and they are used with EC Diffie-Helman in a certain construction that actually gives you _more_ forward secrecy than NaCl box. NaCl Box offers you no forward secrecy, whereas all the ECDH-ES algorithms in JWE offer you partial forward secrecy, which saves you when the sender key is leaked, but not when the receiver key is leaked. That's the best you can get: we can't have a two-way perfect forward secrecy in non-interactive protocol like JWT since we can't perform a direct negotiation of ephemeral keys between sender and receiver). Of course, we're actually comparing apples to oranges here: you can get the same partial forward secrecy guarantee with libsodium's sealed box (not in the original NaCl): [https://download.libsodium.org/doc/public- key_cryptography/s...](https://download.libsodium.org/doc/public- key_cryptography/sealed_boxes.html)

As for an alternative to JWT/JWE, I think it really depends on what people want, but I have slightly different suggestions:

1\. For simple access tokens in low-medium load scenarios, access tokens stored in Redis are probably simpler to implement than JWT + revocation.

2\. If you don't have any secret information inside the token, HMAC-SHA256.

3\. If you have secret information, I'll actually go with libsodium's XChacha20-Poly1305 AEAD: [https://download.libsodium.org/doc/secret- key_cryptography/x...](https://download.libsodium.org/doc/secret- key_cryptography/xchacha20-poly1305_construction.html) secretbox doesn't support AEAD, but you often have external data that you want to tie the token. It's very easy to implement exactly the same construct with XSalsa20, so it will really be just secretbox with AEAD support, but that's non-standard and you won't find any native library support.

4\. Public signature of public data with Ed25519 (this is NaCl's crypto_sign).

5\. Authenticated asymmetrically encrypted tokens: to get partial forward secrecy, the easiest way would be using sealedbox and then signing the result with crypto_sign. It's not the most efficient way to do this, but NaCl/libsodium don't have a tailored operation for this use-case, so you would have to use primitives directly.

All in all, not quite clear cut, and nobody is making a library that does that for you, so it's easy to see where JOSE is coming from.

</comment><comment><USER35> He should release "JWT-H2O" i.e. JWT with HMAC 256 Only. :) (left a similar comment on his blog)

</comment><comment><USER36> One should always validate algorithm before doing anything with JWT on the server side.

</comment><comment><USER37> This is acronym heavy. Author needs to specify in the opening which JWT he is talking about. Java Web Toolkit? or JSON web token? It took me a fair amount of reading to work out which one he means. And even them I'm only pretty sure he means JSON web token, but I can't be sure because the Java Web Toolkit also connects to servers, and uses encryption, and all the other stuff he talks about.

<comment><USER38> People still use Java Web Toolkit?

Okay, dumb jokes aside, they're clearly talking about alternative ways to authenticate, so I wouldn't know how you could conclude this was about anything but JSON Web Tokens.

<comment><USER37> People still use Cobol, mate.

Just specify in the first sentence what you are talking about as full words. Is it that hard? Apparently it is.

<comment><USER39> > _People still use Cobol, mate._

Which makes sense. It has been a historically succesful language that served well for decades.

JWT wasn't even good when it was new.

</comment></comment></comment></comment><comment><USER40> sessionstore and give your client a cookie.

</comment><comment><USER40> JWT is just storing more info than you would with a cookie but pretending it's secure by encrypting it with an algorithm the browser has access to.

<comment><USER41> JWT are not encrypted, they include an HMAC signature to prove that the token claims (which are a Base64 encoded JSON object) have not been modified.

<comment><USER42> JWT can be encrypted. [https://tools.ietf.org/html/rfc7519#page-26](https://tools.ietf.org/html/rfc7519#page-26)

</comment></comment></comment><comment><USER38> Oh hey, it's another "JWT libraries used to be terrible" article.

Idiots shouldn't write authentication code. Especially when credentials are involved.

Funny jwt-go was used as an example; it was never vulnerable to the alg-none attack: [https://github.com/dgrijalva/jwt- go/commit/2b0327edf60cd8e04...](https://github.com/dgrijalva/jwt- go/commit/2b0327edf60cd8e04d7ee6670b165c9580a42392)

<comment><USER43> >> it's another "JWT libraries used to be terrible" article

Dead on. Sure, some early JWT implementations were poor... during the first few months that JWT was gaining traction. That was over 2 years ago. You may as well write an article about how Internet Explorer is awful, while referring to qualities present in IE 6. Disclaimer: I still dislike IE/Edge, but no longer have pertinent reasons as to why I maintain that opinion.

There is not a single valid criticism of JWT from a security perspective. The only criticism outside of security considerations I'd view as valid is that the length of the strings quickly becomes bloated for the amount of information contained within (ie: inefficient bandwidth and storage usage, the same complaint as with long cookie headers requiring more TCP packets).

<comment><USER4> Usability and implementation errors are security errors

[http://blogs.adobe.com/security/2017/03/critical- vulnerabili...](http://blogs.adobe.com/security/2017/03/critical- vulnerability-uncovered-in-json-encryption.html)

see the "X.509" section here [https://www.npmjs.com/package/jsonwebtoken](https://www.npmjs.com/package/jsonwebtoken)

[https://twitter.com/bcrypt/status/583070541336195072](https://twitter.com/bcrypt/status/583070541336195072)

</comment></comment></comment><comment><USER44> Huh? The alternatives listed make me wonder if the author actually knows what JWT is being used for.

</comment><comment><USER45> hey, author is missing the bit where you can disallow client to choose the algorithm. No need to read the rest...

<comment><USER46> In some way he addresses that towards the end:

> It's important to note that my experiment is not JWT.

> When you reduce JWT to a thing that is secure,

> you give up the "algorithm agility" that is a proud part

> of the specification.

I don't agree with him though, unless the standard requires to implement all of the available algorithms, one may choose to implement only those that he/she deems safe/worth.

<comment><USER47> >I don't agree with him though, unless the standard requires to implement all of the available algorithms, one may choose to implement only those that he/she deems safe/worth.

Agreed. I view this flexibility as a developer feature, not a client feature.

<comment><USER48> Correct. Let's say you implement RSA2048 and server-side reject all other algorithms. Then during a security audit the crypto guy points out that RSA2048, while not broken per se, is not up to the generally-accepted 128-bit security threshold. You should use RSA-3078+ or switch to ECDSA. You decide to switch to ECDSA for the space savings. But what about all the deployed clients? Well since it's not actually broken, you continue to accept RSA-2048 for the next couple of years until something else permanently breaks support for old clients. Supporting client-specified algorithms lets you do a safe, phased-in upgrade without breaking compatibility or any fancy engineering.

</comment></comment></comment></comment><comment><USER49> One of the advantages in using JWT is that the verification is in the cpu level and not a lookup via disk. This may sound strange, but if you don't have a quick lookup cache or centralized cache, This would be a great advantage to use CPU.

<comment><USER4> This is not a cryptographically sound argument

</comment></comment><comment><USER50> So we should stop using cell phones because one implementation happened to spontaneously combust. Got it.

Or maybe - just maybe - the claim that specifications should be judged by their implementations is entirely nonsensical. The fact that Internet Explorer exists doesn't in and of itself mean that web browsing as a whole is a defective concept. The fact that single-ply toilet paper exists doesn't mean we should stop using toilet paper. Likewise, the fact that some JWT implementations are defective does not in and of itself say a whole lot about JWT itself.</comment>


Judge: child porn evidence obtained via FBI's Tor hack must be suppressed - <AUTHOR> http://arstechnica.com/tech-policy/2016/09/judge-child-porn-evidence-obtained-via-fbis-tor-hack-must-be-suppressed/ <comment><AUTHOR> > Earlier this year, federal judges in Massachusetts and Oklahoma made similar > rulings and similarly tossed the relevant evidence. Thirteen other judges, > meanwhile, have found that while the warrants to search the defendants' > computers via the hacking tool were invalid, they did not take the extra > step of ordering suppression of the evidence. The corresponding judges in > the remainder of the cases have yet to rule on the warrant question.

It's nice to see checks/balances work every now and then. It's also refreshing to see public figures stand against "thinking of the children" when rendering judgements about our freedoms. My only concern is that it's still a narrow technical ruling, only invalid because the judge issuing the warrant did not have the authority to do so (it targeted people outside their jurisdiction), and while it's relatively easy in the physical world to constrain your search, it's much more difficult on the digital world unless the warrant is extremely narrow in scope. Once you've gotten access to someone's personal computer, you're going to get _all the things_ , not just the child pornography. I would consider it the equivalent for getting a warrant (hand-wave the actual execution) to mount a GoPro your target and record their life, combing through the footage to find details relevant your case, but I fear a "hack their computer" warrant would be/is much easier to obtain.

<comment><USER2> I think that a warrant that allows the exposure of your IP address through intrusive software that exploits a security weakness is valid, assuming that you receive the software after visiting a site and performing a criminal action. It's suitably narrow, and allows further (appropriate) searching.

The alternative (that I can't say that I mind too much, either) is to prohibit ever catching Tor users no matter what online criminal activities they perform, assuming you can't get their real IP through other means.

<comment><USER3> Generally I'd like to see something like an "Internet District" court with technically trained judges that have jurisdiction over warrants on the internet.

<comment> gm-conspiracy Maybe a "World Police"?

[https://en.wikipedia.org/wiki/Team_America%3A_World_Police](https://en.wikipedia.org/wiki/Team_America%3A_World_Police)

<comment><USER3> Well we're already that :-). But leave the internet-level stuff to judges who focus on that, instead of the one closest to some random fbi office. At least that way the judges can see & learn how these things play out, and give some informed judgement that has a chance of setting good precedents.

<comment><USER4> Of course we'll have to call them "cyberjudges"

</comment></comment></comment></comment></comment></comment><comment><USER5> "As a way to ensnare users, the FBI even took control of Playpen and ran it for 13 days before shutting it down."

Shouldn't the agents running this site be charged with child pornography distribution? Or are they above the law?

This would be a full blown investigation against the police in this country (Norway), but here entrapment is illegal too.

<comment><USER6> Unfortunately we've seen that law enforcement in the US is able to get away with doing some rather despicable things in the name of fighting crime.

Personally, I don't believe it's moral or ethical for law enforcement to commit crimes in order to catch criminals. After all, how can we defend our own morals and ethics if we're willing to ignore them for "reasons"?

<comment><USER7> > Personally, I don't believe it's moral or ethical for law enforcement to > commit crimes in order to catch criminals.

I think you want to look at systemic effects and the potential for bulger- style corruption. Distribution of child porn does not do direct harm. It does harm by being a system that supports child abuse and we have collectively decided that child abuse is harmful enough to the fabric of our society that it is worth dismantling the systems that support it.

So here, the ends justify a certain scoped set of means, but also impose a duty of competence in deploying those means and a duty to stay within their scope.

Note that We don't currently have any penalties for crossing the bounds of that scope.

<comment><USER8> > Distribution of child porn does not do direct harm. //

IMO it does, both to the user and the subjects of the pornography.

It's most likely the lesser harm compared to the original creation; though I'm not sure you could certainly say that in absolutely all situations.

</comment></comment></comment></comment><comment><USER9> easy fix for the prosecution: Use parallel reconstruction. I'm sure they're on this as we're commenting here.

Once the information has been gathered, it's out there. You can't unsee it. It will always be there. Now, I don't think we should protect child porn users, but this is a general issue with mass surveillance. Laws change and suddenly somebodies actions that were once legal and are now illegal will be useful for the investigators as a basis for parallel reconstruction or just plain extortion or blackmail.

<comment><USER10> Parallel reconstruction is not so easy when the case is already at trial as you can bet the defendant will not be doing whatever it is law enforcement need to now find evidence of. Time machines are still not available.

<comment><USER9> No. But they can find other means of proving that the defendant has done what you know they have done.

<comment><USER11> I agree with everything you've said thus far, however, I'm still curious as to how the Π would go about reconstruction w/out using their already gathered knowledge to get warrants/subpoenas.

They could hope the ∆ was using BT and had their IP logged for downloading copyrighted material. Then maybe request a warrant for their computer that way but that seems like a stretch.</comment></comment></comment></comment>


Ask HN: How do I communicate to my team that our app design is now mediocre? - <AUTHOR> Since, design is a very subjective thing. How do I communicate to my design and product team that we used to be an amazingly design product (both visually and user experience point of view), and with every new iteration we are not getting any better. Worse, we are getting mediocre at many things.
There was a time when we used to be obsessive about every single pixel and the number of clicks to do X.
Now the team has too much to do and lesser focus on details.
The only solution I see is either getting my hands dirty and deep diving into it. Or hire someone who can give a sense of direction to design team.
Any tips? <comment><USER2> 'team has too much to do' seems to be the real problem. Will your solutions lessen the team's workload or increase it due to micromanagement?

Seems to me the easier solution is to lessen their load directly, push back dramatically on deadlines, force vacations/breaks for them to unwind, and try to inculcate pride in work by increasing ownership and financial rewards. Maybe pay for design conferences, courses, museum/gallery visits or a trip to Japan/Switzerland.</comment>


Computer solves a major time travel problem - <AUTHOR> https://cosmosmagazine.com/physics/computer-solves-a-major-time-travel-problem <comment><USER2> How is the first solution a new solution?

The Marty descending by the time-travelling Marty who "becomes his own grandparent" either has other genes than the original Marty (and thus is either another person, not the one that originally came, which maintains the paradox), or always was his own grandson (so this new solution is just the already known time-loop solution a la 12 Monkeys).</comment>


Debian-installer, mdadm configuration and the Bad Blocks Controversy - <AUTHOR> http://strugglers.net/~andy/blog/2020/09/13/debian-installer-mdadm-configuration-and-the-bad-blocks-controversy/ <comment><USER2> > If you're on something with multiple virtual consoles (like if you're > sitting in front of a conventional PC) then you could switch to one of those > after you've entered the MD configuration part and modify /tmp/mdadm.conf > then. I don't have that option because I'm on a serial console.

debian-installer starts a screen session these days when installing over a serial console.

You can reach the previous and next consoles with Ctrl-a n and p.

<comment><USER3> Hi, article author here. That's interesting! I'd possibly never noticed this because my serial console session has always been itself inside screen (now tmux with screen bindings), so doing that would only ever have sent me to my own next window!

I'll have to try it again next time I am in there, with a double escape.

</comment></comment><comment><USER4> > Currently the only way to remove a BBL from an array component is to stop > the array and then assemble it

This worked for me without stopping the array:

      mdadm /dev/md127 --fail /dev/sda --remove /dev/sda --re-add /dev/sda --update=no-bbl

Not ideal, because it degrades the array for a moment, but hey.

<comment><USER3> Hi, article author here. I just tried that out on an Ubuntu 18.04 machine but it didn't work:

      $ sudo mdadm --fail /dev/md0 /dev/sdb1 --remove /dev/sdb1 --re-add /dev/sdb1 --update=no-bbl
      mdadm: set /dev/sdb1 faulty in /dev/md0
      mdadm: hot removed /dev/sdb1 from /dev/md0
      mdadm: --re-add for /dev/sdb1 to /dev/md0 is not possible
      $ sudo mdadm --add /dev/md0 /dev/sdb1 --update=no-bbl
      mdadm: --update in Manage mode only allowed with --re-add.
      $ sudo mdadm --add /dev/md0 /dev/sdb1
      $ sudo mdadm --examine-badblocks /dev/sdb1
      Bad-blocks list is empty in /dev/sdb1

Any ideas why? md0 is a simple RAID-1 metadata version 1.2 array.

<comment><USER5> I added

[https://raw.githubusercontent.com/prgmrcom/ansible-role- mdad...](https://raw.githubusercontent.com/prgmrcom/ansible-role-mdadm-bad- blocks/master/files/fix-md0)

for you.

Apologies I haven't gotten to your PR's yet, but there is a ticket now in our internal development queue to review and merge those.

<comment><USER3> Interesting. What's the sfdisk for? Is that why my attempts to use --re-add aren't working?

I also tried "mdadm --zero-superblock /dev/sdb1" to make mdadm forget that was ever an array member, but that didn't get me any further.

I use Debian so this won't help me directly, but once I work out why I can't re-add it will be possible to use something similar in a postinst hook to rebuild all the arrays.

<comment><USER5> The sfdisk is because as part of our kickstart file we only create the first partition. After removing the disk from the raid we repartition it.

I don't see why this couldn't fix up a RAID device generated by the debian installer. The device name could be parameterized if it's not always the same.

We run this script before there's any real data on the device so loss of redundancy for a brief moment is not a huge deal - md0 is a very small device so it doesn't take long to resync.

<comment><USER3> But why do you repartition it?

Doesn't putting the exact same partition table on a device that already has a partition table result in no actual changes?

<comment><USER5> We repartition it because we're adding partitions.

We have one kickstart file that we use regardless of medium type. For SSDs, we overprovision and leave unused space at the end. Some brands of SSDs were failing before we did that. We don't need to overprovision hard drives.

You could remove the repartitioning and it would do the right thing for your use case.

<comment><USER3> Ah okay. It seems that my re-adds were failing on arrays that don't have a bitmap. I was testing it on small arrays that don't get a bitmap by default.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> bad blocks on harddisks are also often remapped when written to. However in my (limited) experience once you get badblocks the disk detoriates often. So this badblocks feature is probably not as useful because the harddisk firmware is the only place that knows about badblocks and "lies" to you.

However for deciding if an old disk is still usable I've found that overwriting the whole disks multiple times with the badblocks utility ([https://linux.die.net/man/8/badblocks](https://linux.die.net/man/8/badblocks)) - if the disk passes multiple runs without generating new bad blocks it's often still usable

<comment><USER4> linux.die.net man pages tend to be badly outdated. And you can't easily tell this is the case, because because they strip version information.

For example, this one doesn't document the -B option, which was added in 2011(!):

[https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/...](https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=e53e8fb00970fc74)

Better man page link:

[https://man7.org/linux/man- pages/man8/badblocks.8.html](https://man7.org/linux/man- pages/man8/badblocks.8.html)

<comment><USER7> If you use Debian, I would suggest [https://manpages.debian.org/stable/e2fsprogs/badblocks.8.en....](https://manpages.debian.org/stable/e2fsprogs/badblocks.8.en.html) (where you can replace "stable" with whatever designator you like.)

</comment></comment></comment><comment><USER8> This is insane. I've been using md-raid for over a decade now and I had no idea this crazy feature existed... Now I wonder if it has been involved in some of the trouble I've had in the past.

</comment><comment><USER9> > Even if the particular part of the device is unreadable, the operating > system is supposed to try to write the correct data over the top.

According to md(4) man page, that's what it does. Only if the _write_ fails, it is added to the bad block list.

FWIW, I've also encountered an issue related to BBL - in my case multiple RAID6 components got bogus bad blocks (no idea from where, maybe a lower-level controller issue or driver bug?) so there were logical sectors that had insufficient non-"bad" backing sectors and the RAID array reshape process code was seemingly not prepared for that, entering an infinite loop with 100% CPU use and locking all use of the array.

</comment><comment><USER10> I know this is going to sound trite, but this is precisely the reason I don't use mdadm

I really don't like lvm either, but in some cases its the only real way to join larger hardware arrays together (for example some arrays will not let you stripe multiple raid7s instead insisting that you have a 50drive raid 7 array. No dice.)

This is where ZFS really does shine here. The control, visibility and documentation are just wonderful. Its almost as good as reading a redbook.

For the hobbyist I don;'t see any reason why you'd really want to have an mdadm array, barring the slight edge of performance when you are running at >75% capacity.

<comment><USER11> > For the hobbyist I don;'t see any reason why you'd really want to have an > mdadm array

The "don't even dare to use ZFS without dedicating 8-16 GB of memory to it" warnings all over the ZFS documentation online has served as a very, very good reason for me to not use ZFS for anything at all.

I'll stick with tooling that lets my homelab actually have enough RAM to run the applications I want to run.

<comment><USER12> > don't even dare to use ZFS without dedicating 8-16 GB of ECC [!] memory to > it

Fixed that for you.

Now, I've since build a storage server for my homelab using ZFS, but mdadm is far more accessible. It also feels easier - I know what's on the drives and how it is stored. In case of something strange happening with ZFS, I don't have any hope except backups. Also, ZFS lacks support in most distributions and somewhat obscure encryption capability.

I don't mean to bash ZFS here - it's great. But the GP feels like it's saying "I don't see why would anyone not want to run a dedicated kubernetes cluster with HA for running a program on Linux".

<comment><USER10> > GP feels like it's saying "I don't see why would anyone not want to run a > dedicated kubernetes cluster with HA for running a program on Linux".

Thats not quite right

Its more that the documentation, command line interface and general user setup is far more friendly than mdadm. I've been a sysadmin for many years, and looked after innumerable file servers, from clustered XFS (!) through many years of lustre, plain old XFS/ext2/3/5 on HWraid to netapps&isilons, and all sorts of flash in the pan appliances.

Barring GPFS, the only file system that has documentation and tooling that is simple to understand and doesn't immediately bite you in the arse is ZFS.

Kubernetes is neither simple, easy or quick to setup, or run.

</comment></comment></comment></comment><comment><USER13> Ugh, please don't "\--assume-clean" on new raid arrays. Let the os build the array from the ground up. Then when its done scrub it.

from the documentation: "assume-clean: Tell mdadm that the array pre-existed and is known to be clean. It can be useful when trying to recover from a major failure as you can be sure that no data will be affected unless you actually write to the array. It can also be used when creating a RAID1 or RAID10 if you want to avoid the initial resync, however this practice — while normally safe — is not recommended. Use this only if you really know what you are doing."

<comment><USER3> It's on new devices in an installer context for a RAID-1 as the text you quote describes, so yes I do know what I'm doing. But fair enough, it might give other people bad ideas, so I'll remove it from the examples.

</comment></comment><comment><USER14> > the mdadm binary in d-i is compiled to have its config at /tmp/mdadm.conf. I > don't know why, but probably there is a good reason.

It's certainly because all else of the installer file system hierarchy is mounted read-only I would think.

<comment><USER15> When you're booted in the installer environment, /etc is writable. Some of the sample code in the article shows writing a file in /etc, and the file write works fine, mdadm just doesn't read the file.

I believe the reason is that mdadm in the installer exists to create arrays for the installed system, so the installer's RAID configuration needs to supply a configuration file, and for some reason that's handled by having the installer's RAID configuration write it to /tmp/mdadm.conf and having mdadm read it from there. (Rather than, say, writing it to a temporary file and directing mdadm to read that temporary file.)

<comment><USER16> Well, /etc/mdadm.conf is supposed to describe the running system.

Now, the installer doesn't use md, but from a strict philosophical perspective this makes sense.

</comment></comment></comment><comment><USER17> I didn't know about this "feature", but to be honest I have learned years ago not to use the partitioning features of the debian installer. It's just another crude tool to fight with, while the real tools are just a console away.

Here's a list of the things the debian-installer can't do, or at least couldn't do when I needed it:

\- accurate partitioning, such as choosing between GPT or MBR partitioning

\- filesystem features (btrfs subvolumes, ext4 flags)

\- creation of crypt volumes with keyfiles

\- having user control over the names of crypt devices

\- using an existing crypt device WITHOUT formatting it

\- mdadm write-intent bitmap enabling/disabling

<comment><USER3> By choosing "expert" mode you can choose between any of the partition types (much more besides mbr and gpt). In standard mode it will pick mbr if none of your devices are bigger than the mbr partition limit (2TB?) otherwise it will pick gpt, without offering you a choice.

You can choose expert mode at the start when you boot the installer or you can switch to it from the menu once it's started.

I think you may be right about the other things, but this is not uncommon amongst OS installers. It is very hard to offer the full range of configurations available from all of the tools used to install a Linux system, without just putting the user at a shell prompt and letting them get on with it. Luckily that option is still there!

</comment></comment><comment><USER18> Instead of avoiding a BBL at creation time, it seems like it might be less effort to just let it go ahead and create one then, and then remove it before first putting the array into production.

The removal procedure described in the article seems pretty straightforward. The only problem with it seems to be that have to take your server out of production while you do it, which only applies after the server has entered production.

<comment><USER3> To remove the BBL from the devices that make up the array that the root filesystem is on you would need to boot into a rescue environment and assemble it there.

While the debian-installer does provide the rescue environment that you need to do this, it is by no means trivial.

Speaking as the article author I find it way way simpler to create the arrays from the shell at the start, rather than have to remember to reboot into d-i again, choose the rescue mode, tell it not to automatically assemble, drop to shell and assemble there. It's also faster — most of my servers take more than 60 seconds before even the serial-over-lan starts to display output!

</comment></comment><comment><USER5> There is another discussion which may be worth having: why was this feature enabled by default without considering how the software is used? What process was missing? Is this still a problem, and if so is it pervasive to Linux kernel development or is it specific to md?

</comment><comment><USER19> If your hard drive has bad blocks it really needs to be replaced, it cannot be trusted. You should never have to deal with this.

I don't understand the mentality of dealing with bad blocks in the first place.

Storing data is easy. Storing data reliably is a whole other thing.

<comment><USER20> To add to this, even though bad blocks are allowed by the contract between a device and the OS, because they are so rare, all code paths that deal with them are riddled with bugs.

For example, if you power off a disk improperly, all un-acked writes are allowed to contain a mix of the new data, the old data, or an unreadable sector.

If, on Linux, you now try to read one of those unreadable sectors, you will get an IO error - as designed. If you now try to write that sector, you won't be able to. Why? Well the kernel cache is 4k sectors, whereas the disk is 512 byte sectors, so to write a disk sector it needs to _read_ the other nearby sectors to populate the cache.

That pretty much means every time you power off a disk improperly, you'll get a bunch of unreadable data and filesystem errors, even though the filesystem is journaling so should be able to cope with a sudden poweroff just fine.</comment></comment>