@briankrebs That explains all the shite I've seen, incl. the #CryptoAPI #backdoor in #Windows itself...

@briankrebs That explains all the shite I've seen, incl. the #CryptoAPI #backdoor in #Windows itself...
@iX_Magazin #Windows ist inhärent unfixbar unsicher...
Siehe #CryptoAPI - #Backdoor!
@euroinfosec which doesn't matter when they literally #backdoor the #CryptoAPI and integrate #Govware like #Recall!
@cR0w too many.
http://github.com/kkarhan/windows-ca-backdoor-fix
So far testing by @ct_Magazin / @heiseonline (and myseof later on) revealed only few #Apps not vulnerable to this specifics #Govware:
Anything else that uses the CryptoAPI is, espechally *all #Chromium-Forks (aka. All Browsers except Firefox, Tor Browser, #dillo, #LynxBrowser…)
USpol, Trump, US-centric Internet Infrastructure, National Internet Blackout
@marjolica @utf_7 @dashjackson @froge @arstechnica It'll impact any application that uses #Windows' #CryptoAPI and doesn't come with it's own #Encryption Library and #CertificateManagment.
Needless to say all #Chromium variants and #IE / #Edge are vulnerable to this #Backdoor which exists since at least #WindowsXP to this day!
@GossiTheDog @signalapp it merely prevents #Screenshots by claiming it's #DRM'd content.
It's a mere ask and #Microsoft could specifically close that #API and make it subject to contractual agreements (as they did with their #Antivirus API calls to disable #WindowsDefender!) if they decide this is against their wishes.
It also doesn't prevent the #Keylogger nor works against the known #CryptoAPI #backdoor affecting all #Browsers (except #Firefox and @torproject / #TorBrowser) which can be triggered by a single #HTTPS request.
The correct solution for #Signal would be to alert all their users and specifically block #Windows in general or at least #Windows11 simply because it is a #Govware and empirically cannot be made private or secure.
But that would require them to actually give a shit, which thed don't, cuz otherwise they would've stopped demanding #PII like a #PhoneNumber and moved out of juristiction of #CloudAct.
Since they are highly centralized.they certainly are capable to comply with "#Sanctions" (or whatever bs he'll claim!)...
@DeltaWye @kfh I'd say @torproject / #TorBrowser as it's #Firefox but without #tracking, #adware and #analytics!
But if you're using #Govware like #Windows, any #Browser that doesn't use the #backdoored #CryptoAPI (i.e. all #Chromium-Forks do use it!) is better...
@paco #Copilot & #Recall are the perfect #InfoStealer #malware combo!
@cryptrz add to that the fact that the #CryptoAPI is #backdoored and that said #backdoor can be triggered with a simple #HTTPS request in any #Browser [except #Firefox & #TorBrowser as they use #NSS instead!] (or #PowerShell's horrible wget
implementation)...
And we have sufficient proof thaf #Windows is a #Govware that noone should use and that should be banned across the globe.
@0x40k well, #Microsoft to this day has a #Backdoor in the #CryptoAPI that remains unfixed to this day...
@roman78 @admin @olifantenbaer angesichts der Lücken in #CryptoAPI inklusive #Backdoors ist das digitales #FlexTape bei durchgerrostetem Rohr...
@gborn @MichaelD @Bundesligatrainer @Ihazchaos nein, eben nicht.
Dass #Windows10 [und besonders #Windows11] nicht #DSGVO- & #BDSG-konform sein können ist evidenzierte Tatsache und ich habe noch keine*n Anwält*in gesehen die etwas anderes behaupten und dafür im Zweifelsfalle auch die #Haftung übernehmen würden.
Wohingegen ich mir sicher bin dass @SUSE & @ubuntu mir im Zweifelsfalle sogar ne #Versicherung der #Compliance ab Werk anbieten würden, was #Microsoft aufgrund von #CloudAct inhärent nicht kann!
Außerdem verbietet sich das Procurement von Anbietern die in "illegaler Agententätigkeit" [u.a. #PRISM] involviert sind (!!!) schon aus oberflächlicher due diligence...
Von einfach ausnutzbaren #Govware - #Backdoors in der #CryptoAPI unter #Windows hab ich noch garnicht angefangen!
@puppygirlhornypost2 @navi yeah, but that's a common problem based off #TechIlliteracy and lack of proper explaination!
Bonus points if #TPM bs prevents #DataRecovery.
@vvelox @SecurityWriter I trust noone, but unlike #Microsoft, #RedHad didn't betray it's paying customers by literally shoving #Govware #Backdoors into critical compontents like the #CryptoAPI...
@tokyo_0 #TrueCrypt is #abandonware with serious security issues.
Use #VeraCrypt or even better: migrate machines to #Linux and use #LUKS / #dmcrypt instead, as it's the best option at hand.
"Encryption at Rest" for JavaScript Projects
Following a previous post (https://infosec.exchange/@xoron/113446067764347249), which can be summarized as: I'm tackling state management with an extra twist: integrating encryption at rest!
I created some updates to the WIP pull-request. The behavior is as follows.
- The user is prompted for a password if one isn't provided programmatically.
- This will allow for developers to create a custom password prompts in their application. The default fallback is to use a JavaScript prompt().
- It also seems possible to enable something like "fingerprint/face encryption" for some devices using the webauthn api. (This works, but the functionality is a bit flaky and needs to be fixed before rolling out.)
- Using AES-GCM with 1000000 iterations of PBKDF2 to derive the key from the password.
- The iterations can be increased in exchange for slower performance. It isn't currently configurable, but it might be in the future.
- The salt and AAD need to be deterministic and so to simplify user input, the salt as AAD are derived as the sha256 hash of the password. (Is this a good idea?)
The latest version of the code can be seen in the PR: https://github.com/positive-intentions/dim/pull/9
I'm keen to get feedback on the approach and the implementation before i merge it into the main branch.
"Encryption at Rest" for JavaScript Projects
I'm developing a JavaScript UI framework for personal projects, and I'm tackling state management with an extra twist: integrating encryption at rest!
Inspired by this React Hook: Async State Management (https://positive-intentions.com/blog/async-state-management), I’m extending it to support encrypted persistent data. Here's how:
The Approach:
Using IndexedDB for storage.
Data is encrypted before saving and decrypted when loading using the Browser Cryptography API.
Event listeners will also be encrypted/decrypted to avoid issues like browser extensions snooping on events.
The password (should never be stored) is entered by the user at runtime to decrypt the data. (Currently hardcoded for now!)
The salt will be stored unencrypted in IndexedDB to generate the key.
Proof of Concept:
You can try it out here: GitHub PR (https://github.com/positive-intentions/dim/pull/8). Clone or run it in Codespaces and let me know what you think!
Looking for Feedback:
Have I missed anything? Are there better ways to make this storage secure?
Let's make secure web UIs a reality together!
@rysiek #Microsoft blaming the #EU for #CrowdStrike when the most affected customers are #Airlines from the #USA that don't eben service Airports in #Europe at all is the biggest insult to the intellect of everyone since they denied #_NSAKEY and their #CryptoAPI #backdoor:
@malwaretech thanks for adding another legendary #ITsec #fuckup by #Microsoft to the long list of *"#WontFix" #Exploits that prevent me from even touching #Windows at all...
If a literal #Govware #Backdoor in the #CryptoAPI wasn't worse enough already...