One of the applications they suggested is MFA. If you're validating mfa on the client side you are doing it wrong.
They give 3 ways to deal with MITM attack. PKI isn't mentioned as one of them. Who the hell tries to deal with MITM by looking at network timings?
There's a reason that the api has subtle in the name, its because using it naively will shoot yourself in the foot. Unless you have a very specific usecase,leave the crypto to the tls layer.
> Unless you have a very specific usecase,leave the crypto to the tls layer.
Author should delete that blog post. Normally, I wouldn't suggest that, but since this is dealing with security, it should thoroughly scrutinized, especially since there are so many JS noobs just starting their careers and they might look at this post as best practices.
I got no issues with it inside a browser extension, because a Website cannot change the Code running there, correct?
What I mean is, an advertisement could simply override the crypto API and do whatever it wants with it.
You should also add subresource integrity as a defence in depth. https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
But then that raises the question of why you need crypto if everything is already encrypted and verified via TLS.
There are probably a couple obscure unique usecases (maybe if you're doing some p2p stuff with webrtc), but i'm pretty convinced client side crypto on the web is useless 99% of the time.
Depends where the TLS path terminates and what your threat model is. If I send a message via a service (an email via gmail.com for instance) the message is only protected by TLS as far as that provider. If the content itself is encrypted as well as the transport (and that provider does not know the keys) then the message is still protected at that point. This could be important for code sending data via an API proxy of some sort.
Also remember that the user of the browser might not have control over what certificates are trusted for HTTPS purposes. If they are operating in an environment where a local CA certificate is installed and that is used by a transparent proxy to enable them to inspect otherwise secure streams, the application protecting the content as well as the transport may protect against that (though you'll be wanting to use PKI here - otherwise you have a key distribution problem).
I'd argue that I would like to see more client-side crypto. I'd prefer my data to be stored encrypted and inaccessible to third parties such as Google. Google Drive or Dropbox would get my business back instantly if they supported client-side encryption of data. Of course, in Google's case, that would completely break the business model of mining us for every ounce of data.
If the page is dynamic, not everything can be linked into that hash, but paired with CSP you can 100% guarantee that any code that executes is coming from a trusted source.
Then there's technologies like DNSLink for IPFS that obviate the need for this altogether, since the DNS response just contains the hash of what you want, and you ask IPFS for that hash, and anyone who's got it can deliver it to you.
>Sometimes, hackers can steal users’ passwords. So, even if these passwords are hashed or encrypted in the database, it can’t stop them from accessing a user’s account. To make sure that someone who’s accessing an account is the true owner, applications allow multi-factor authentication.
>Rather than using transport-layer authentication, such as TLS client certificates application can use suitable client keys which may have been previously generated via the user agent like multifactor tokens.
I could not follow this part. With FIDO, you have should have a Trusted Platform Module or Hardware Security Key to store the secret key, but I'm not sure what is being suggested here.
In the section on "How to deal with man in the middle attacks", there is no mention of TLS 1.3, which would be the #1 thing on my list.
Most software developers generally are not formally trained in security as a separate domain of knowledge. If you think security is something that can be passively acquired by reading a few APIs you are wrong. This is why employers require certifications for security work that software development otherwise doesn’t require.
Cryptography was one of the most challenging domains/chapters in preparation for the CISSP. This is because real world cryptography implementations comprise various different cryptographic functions doing different things, such as: certificates, encryption, signatures, hashing, and so forth. The different crypto functions serve different purposes because they have different pros and cons. There isn’t some encryption blanket solution.
The gold standard is still CISSP for the corporate world. It is more of a managerial standard. The best study guide is the official course book: https://www.amazon.com/Certified-Information-Security-Profes...
The standard most prized by government and security researchers is GIAC from Sans.
To take the CISSP you have to apply for the exam because there are prerequisite criteria and the exam costs $700. Even still it only has around a 60% pass rate. The GIAC tests are supposed to be much harder and are extremely expensive. I passed the CISSP but have never taken any of the GIAC tests.
There's lots of different types of security stuff. If you're interested in the more risk management corporate side, looking at study material for certs like CISSP can be useful (but use it as a starting point of things to learn, dont follow blindly). If you want to learn crypto, that's not the path i would reccomend.
The networking and security industries, on the other hand, require them. Attaining those jobs/skills from the perspective of writing software is the surest way to waste your time and accomplish nothing.
> That’s because you are a developer and not a security manager
These days, I'm neither.. but I am a founder in a security-critical space.
Here are a collection of links that I have, YMMV (theres probably a some overlap in these links):
If you have access to linkedin learning, there are a number of decent resources there also.
EDIT: unrelated to ^, Checkout youtuber "Ippsec" - he does hack the box challenges (retired boxes).
Speakers Site and slides used for ^
For those who dont want to click on PDF (Good stuff) link to site: https://momjian.us/main/
Bruce Momjian is a legend.
If you want to learn more about crypto, there's various books (not sure how up to date , but https://www.goodreads.com/book/show/7602360-cryptography-eng... is a good introduction) https://cryptopals.com/ is also good if you like hands on.
Mozilla docs: https://developer.mozilla.org/en-US/docs/Web/API/Crypto/subt...
In my opinion, more developers should familiarize themselves with the tools and start looking at how they could implement security for their users.
Processing highly critical data, such as PII or financial data, is not a requirement to use cryptography. Starting out, on could well be served by trying it in personal projects or even public data. This way, uncovering a vulnerable design could mean uncovering data that was already meant to be seen.
Some will always argue it's the wrong or the dangerous thing to do, and they will never ship security to their users, I guess.
: For example, the ReactDOM manipulations breaks this security model because SubtleCrypto will only interface with the DOM. There are additional libs as workarounds for these issues tho.
Its literally named subtle to discourage the general developer.
In the https web model, there are very few situations where using this api actually makes sense. (Seriously, i challenge you to name one in a typical server-client web app)
“It is named SubtleCrypto to reflect the fact that many of these algorithms have subtle usage requirements in order to provide the required algorithmic security guarantees.”
This was the closest to an explicit mention of the name I could find right now. It could read both as ‘the api provide security guarantees’ or ‘the developer provides security guarantees’. The article goes on to mention the customary warnings for developers about to do dangerous things.
So yes, I believe you are right on this one. My memory served me otherwise. I still think developers would do themselves and their users a service by learning about applied cryptography and how to securely implement it.
> In the https web model, there are very few situations where using this api actually makes sense. (Seriously, i challenge you to name one in a typical server-client web app)
There are no situations where using this api without HTTPS is even possible. SubtleCrypto is only available in secure context. Making an argument that the api then doesn't make sense in said secure context doesn't resonate with the design choices behind it.
About server-client apps, client-side cryptographic schemes are a thing. I access my encrypted cloud storage provider right now which implements client-side crypto. So are end-to-end cryptography, e.g. two users messaging each other througn a common server. These use-cases are not covered by HTTPS as we know.
Here's a link to some part of Matrix that seem to use this api, but don't take my word for it.
Browser extensions can bypass that though, which can expose you to malicious third parties.
tl;dr: In most cases browser JS crypto offers no advantages if you're trying to protect yourself from a rogue/compromised backend (eg. do e2e crypto on keys stored within localstorage before passing that over to the backend). That is because if the backend is compromised it can likely serve backdoored JS code that will leak secrets.
This is not always true (eg. if you have multiple tiers of server backends within separate security domains), but almost always true for typical web monoliths.
Quote: "As people communicate over the internet, there’s a possibility that others can eavesdrop or even hijack information before it gets to the other parties involved."
Why you would, i dont know. Its a terrible idea like most use cases for js client side crypto, but you could if you wanted to. Then again, cert pinning is a mostly terrible idea in the context of TLS too.
Essentially every software security related subject can be qualified by a single question: What industry trusted process validates your concern?
It looks like this post is from a person in Nigeria. Perhaps this is a scam where they create a blog post targeting JS noobs where they advocate for questionable security practices, making web security a little more vulnerable, therefore making it easier for scammers to exploit client side JS.
If that's the case - bravo, that is some jedi level mind tricking.
Obviously, that is unlikely, but would funny if even remotely true.
EDIT - I take that back, looks like this is the blog of a legit company , though it looks Russian hmmmm