nmadden

12 ms·

151.
by nmadden 5y ago
Older CBC cipher suites padded to the next multiple of 16 bytes (for AES). TLS 1.3 doesn’t support these anymore but added a more general padding mechanism [1]. I don’t know whether any browser actually uses it though. [1]: https:/&#x
152.
by nmadden 6y ago
(Author of the post here). My point is that you can easily make this a complete non-issue by increasing the entropy of the token. 96-bit tokens are 16 characters in base64url - just 3 more characters than the 64-bit tokens used by Waterken,
153.
by nmadden 6y ago
Two points: Your calculations assume that attackers are interested in brute forcing one particular token. But if your app issues a lot of tokens then it becomes easier for an attacker to find some valid token. For example, if you issue a bi
154.
by nmadden 6y ago
Your argument has gone from “this is impossible with capabilities” to “this doesn’t scale” to “nobody uses design patterns”. You are confusing DI frameworks (often terrible) with the general concept of dependency injection, which is in fact
155.
by nmadden 6y ago
The beauty of object-capability security is that it completely aligns with normal object-oriented design. So you can always recast these discussions to not be about security: how would I inject any other new dependency I needed without chan
156.
by nmadden 6y ago
One of the foundations of object-capability security is memory safety, so loading arbitrary native code does subvert that. You can get around this by, for example, requiring native code to be loaded in a separate process. As you say, a capa
157.
by nmadden 6y ago
Typically libraries don’t directly load one another. The language runtime does this.
158.
by nmadden 6y ago
> If a library needs access to a remote service, you have to open the socket yourself and pass that in, and the library then needs to plumb it through the whole stack manually to the point where it's needed. You don't need to d
159.
by nmadden 6y ago
Are you aware of the history of object-capability programming languages? There are multiple actual demonstrations of real-world ocaps programming languages and projects built with them: * The (now defunct) E programming language: http:&#x2
160.
by nmadden 6y ago
That’s just the first example. As the author of that series writes, most of the exploits are not due to memory corruption. Most are confused deputy attacks where privileged code can be tricked into performing dangerous operations.
161.
by nmadden 6y ago
The File example is a good illustration of why Java is _not_ a capability-secure language. Every File object in Java has a getParentFile() method that allows you to navigate up the hierarchy right to the root and then from there access ever
162.
by nmadden 6y ago
Exactly. What usually happens in capability systems is that the main() method gets all the capabilities (or whatever capabilities the user allowed it) and then does dependency injection to distribute those to other components. No need for c
163.
by nmadden 6y ago
Oracle’s own secure coding guidelines for Java [1] actually now recommend adopting a capability-based approach rather than relying on SecurityManager: > FUNDAMENTALS-5: Minimise the number of permission checks Java is primarily an object
164.
by nmadden 6y ago
For cookies... not for Basic Auth.
165.
by nmadden 6y ago
Right - there is no way for the server to tell a browser to stop sending basic auth credentials.
166.
by nmadden 6y ago
“none” has never been a mandatory algorithm. https://tools.ietf.org/html/rfc7518#section-3.1
167.
by nmadden 6y ago
> They can be semantic and in practice are used semantically, especially in nominal type systems. It depends on the programming language how much they enforce though, but even if you don't enforce anything names carry meaning [...]
168.
by nmadden 6y ago
> I would certainly hope that a type "checker" returns a more detailed representation of a program than a parse tree - one in which all expressions are typed and ill-typed expressions cannot be represented. Do you have an examp
169.
by nmadden 6y ago
> I see, it's an interesting line of thought but I think trying to move type checking into the grammar is fundamentally a bad idea. You don't want to mix grammar and semantics because that's not how people think about code
170.
by nmadden 6y ago
Thanks. For what it's worth, the flow of thought was the following: 1. The original "parse, don't validate" essay clearly describes why parsers are preferable to validators. 2. It uses a type system to make illegal state
171.
by nmadden 6y ago
The browser vendors have been looking at this problem for a long time. See https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a... for example (bloom filters included).
172.
by nmadden 6y ago
I use the same technique in my book to show how a REST API can be used to exploit XSS even it it always produces and consumes only valid JSON: https://livebook.manning.com/book/api-security-in-action/cha...
173.
by nmadden 6y ago
No, the statements in Gödel’s proofs are not paradoxes. Substitutions of variables are not the same as interpretations. The interpretation tells you what the nonlogical symbols like *, +, ^, 1, 2, 3 etc mean.
174.
by nmadden 6y ago
It’s not so much that they’re neither true nor false (they’re not paradoxes), but that they can be true in some interpretations and false in others. I wrote up some notes about this here: https://neilmadden.blog/2020/11
175.
by nmadden 6y ago
This is not necessarily true - deterministic EC signatures are now recommended, eg EdDSA or [1] for ECDSA. (To prevent some side-channel attacks you might want to reintroduce some randomness). On the other hand, it’s now recommended to use
176.
by nmadden 6y ago
We’re still waiting to find one of those proper implementations 20 years later.
177.
by nmadden 6y ago
Switch to other proven and mature algorithms eg libsodium, Tink, etc. RSA has not been the only game in town for a long time.
178.
by nmadden 6y ago
See for example Dan Boneh’s “20 years of attacks on the RSA cryptosystem” [1]. Itself now written 20 years ago and the attacks keep coming. [1]: http://www.ams.org/notices/199902/boneh.pdf
179.
by nmadden 6y ago
The point of the article is that mature and well-vetted libraries have repeatedly been shown to have vulnerabilities in their RSA implementations. See [1] for just one recent example, but there have been many. [1]: https://www.cr
180.
by nmadden 6y ago
One day I’d love to find a reasonably priced copy of LiSP. It’s the most elusive widely-recommended book I’ve ever come across.

More ›