Parienve @Parienve@qoto.org

As more walls are raised around gardens and users are even more aggressively preyed upon by greedy corpo overlords, I feel it becomes an #InfoSec community responsibility to arm normal users, not just the tech-savvy, with knowledge and alternatives to break the cycle of exploitation we know drives this business model.

Meta: "MAY I JOIN YOU?"

#meta #fediverse
#MastoArt #krita #HumanMade

There was a solution all along.

Lately I've been interested in cryptography -- which, if you're not a programmer -- is the field of computers involving codes, hidden information, and proof-of-identity.

(Think "security in the form of hard problems involving numbers.")

"Don't roll your own crypto" is a canard frequently incorrectly attributed to Bruce Schneier. Obviously everyone listened and that's why no cryptography exists.

My actual conclusions after a while are:

(1) Basically no one is qualified to invent new cryptographic primitives: hash functions, ciphers, RNGs.

These are the smallest building blocks in a larger cryptographic system, and they're typically defined as simple algorithms (prescribed series of steps) involving 16 letters or so of your message at a time.

The reasons that cryptographic primitives work seem to involve a little bit of math and a lot of praying.

Many are clearly "the first object we could find that (1) had the list of properties we wanted (2) didn't blow up in response to codebreaking techniques." And the problem with that is that -- as Bruce Schneier actually did say -- anyone can invent a scheme they can't break.

(2) You might be qualified to invent a new cryptographic scheme based on existing primitives, but don't bet on it.

These schemes do things like "taking a function designed to encrypt a 16-letter message" and using that function to encrypt a really long message instead.

There's less praying involved here, in that most schemes cash out on the guarantees of an underlying primitive in ways that are recommended by the designers and codebreakers.

For instance, if you use AES -- probably the world's most popular block cipher -- with a random password, you probably do have a random permutation.

(which is to say: for any 16 letters you bonk in, you get a different 16 letters out. Any 16 letters are equally likely to pop out, though.)

You're still likely to invent a system that can be attacked in ways you did not consider, though:

- Many cryptographic schemes fall over when you encrypt multiple messages with the same password.

- It's often possible to extract secret information from the scheme using basic math -- for instance, if the last step of the program is to multiply two numbers, and one of those numbers is known to the attacker, the attacker can usually find out the other one.

- If you reuse a secret value in a less secret context, the attacker can often find out info you would rather the attacker not know.

- Sometimes the attacker can make predictable changes to your message -- changing As to Bs, for instance -- without knowing what the message was.

- Sometimes the attacker can Frankenstein two messages together.

So, OK, it's awful.

... All that aside, I still think it's important for people to write their own cryptography code in private, including implementations of attacks. Something constantly on my to-do list is the Cryptopals self-teaching course:

https://cryptopals.com/

(I'm halfway through set 2)

It's free and there's no corporate bullshit and the problems are really fun. In it you implement a lot of bad cryptography that was (at one point in time) thought to be secure.

If you're a programmer, you should definitely try this -- at least the first two problems. For one thing, it's fun to cut your teeth on.

But I also think that if you haven't cut your teeth on crypto, you can't actually say "don't roll your own crypto." I'm not playing a status game here

At the risk of making a claim that is slightly bold -- I'm saying that at some point you will need to write software that incorporates cryptography, and at that point I don't think you will be able to tell if you actually are rolling your own crypto.

Caveating myself before I even get started: you'll probably be fine if you stick to HTTPS, LetsEncrypt, and stuff like that -- well, you may not be, because you'll be blundering in the dark when it comes to the actual significance of the steps you are taking, but at the end of the day you'll have a server speaking TLS.

But someday, perhaps, you'll be implementing a web app and it needs session keys. Simple, common problem. This isn't even something people look at as cryptography, because it doesn't involve enciphering anything. You'll use UUIDs, right? They're random.

(They're not necessarily random.)

You switch to a real RNG. Well, you're using the RNG class exposed in JavaScript. Well, unfortunately, that's predictable too.

You decide the session key idea is silly and you decide to just send the cookies down to users -- but you'll sign them, using a known, off-the-shelf good signing message.

Whoops, your app is vulnerable to replay attacks.

You switch to JWTs. Whoops, you enabled HS256 and RS256 at the same time. You didn't mean to do that. Why was that even an option? Now anyone can sign anything.

In a "real" cryptographic situation -- one that requires you to design a protocol dealing with data known to be untrusted -- you have more fun outcomes. You're really likely to arrive on known-insecure designs like encrypt-then-MAC, because a horrifying number of online resources recommend that kind of thing. You may decide to use the digest of some public value as a key. (more common bad advice) You may conclude that because you're using a good primitive, like AES, you're not "rolling their own" -- even if you're using a bad mode, like ECB.

And in cases where situational pressures you don't control push you towards specific insecure design decisions, you are unlikely to be able to tell if what you are doing is apocalyptic. You may end up blindly trusting the other side not to lie about its identity because you don't know how fingerprints or cert pinning work. You may end up generating your own keys and accidentally using RSA with a bad prime or a weak key size or something. I don't know, take your pick!

If you expand the definition of "rolling your own cryptographic scheme" to include the entire practical chain of events involved in your use of crypto, then you need to know surprising amounts of crypto just to evade rolling your own crypto.

I do think there's a second tangential set of problems, which is that consumers basically cannot evaluate the cryptographic claims of software. They may assume that because software uses strong cryptography, it is secure in other ways. But in practice, a company that brags about using 256-bit AES is often doing so in an environment where, due to lack of access controls, the data is available in plaintext to anyone.

This isn't totally a cryptography problem though. There are many apps that not only make incoherent crypto claims; the general claims they make about their software are simply not true. See this article for a colorful example: https://crnkovic.dev/testing-converso/

This is still relevant to you because, as a developer, you may be an obtainer of crypto from a second source.

Oof. Isn't it rough?

I hope I've convinced you that being a working developer demands at least a basic knowledge of how cryptography actually works. You probably want to learn the basic details of a few common schemes, and especially you want to learn about schemes that are no longer used because they're broken.

I've really enjoyed the Cryptografurs telegram, which is available here, and which is full of professionals who like to explain things: https://t.me/cryptografurs

Can anyone here recommend some FOSS to visually model a MariaDB schema (offline)?

Conflict-free Replicated Data Types (CRDTs) are a huge opportunity for FOSS projects like LibreOffice, Blender, Inkscape, etc to offer the collaborative features of e.g. Google Docs without involving the cloud!

Put simply CRDTs suggest that if you (re)architect your model right it'll double as your undo stack & give you collaborative editting features. Merge changes as frequently or infrequently as you like, as long as you never merge-conflict.

https://www.inkandswitch.com/local-first/

1/2

Blog post: Writing Python like it’s Rust

https://kobzol.github.io/rust/python/2023/05/20/writing-python-like-its-rust.html

Discussions: https://discu.eu/q/https://kobzol.github.io/rust/python/2023/05/20/writing-python-like-its-rust.html

#programming #python #rustlang

Happy #WorldPasswordDay!

I've cracked billions of #passwords from tens of thousands of #data #breaches in the past 12+ years, and because of this, I likely know at least one #password for 90% of people on the Internet. And I'm not alone! While I primarily crack breached passwords for research purposes and the thrill of the sport, others are selling your breached passwords to criminals who leverage them in #AccountTakeover and #CredentialStuffing attacks.

How can you keep your accounts safe?

- Use a #PasswordManager! I recommend @bitwarden and @1password

- Use a #Diceware style #passphrase - four or more words selected at random - for passwords you have to commit to memory, like your master password!

- Enable MFA for important online accounts, including cloud-based password managers!

- Harden your master password by tweaking your password manager's KDF settings! For #Bitwarden, use Argon2id with 64MB memory, 3 iterations, 4 parallelism. For #1Password and other PBKDF2 based password managers, set the iteration count to at least 600,000.

- Use unique, randomly generated passwords for all your accounts! Use your password manager to generate random 14-16 character passwords for everything. Modern password cracking is heavily optimized for human-generated passwords, because humans are highly predictable. Randomness defeats this and forces attackers to resort to incremental brute force! There's no trick you can do to make a secure, uncrackable password on your own - your meat glob will only betray you.

- Use an ad blocker like #uBlock Origin to keep you safe from password-stealing #malware and other browser based threats!

- Don't fall for #phishing attacks and other social engineering attacks! Browser-based password managers help defend against phishing attacks because they'll never autofill your passwords on fake login pages. Think before you click, and never give your passwords to anyone, not even if they offer you chocolate or weed.

- #Enterprises: require ad blockers, invest in an enterprise password management solution, audit password manager logs to ensure employes aren't sharing passwords outside the org, implement a Fine Grained Password Policy that requires a minimum of 20 characters to encourage the use of long passphrases, implement a password filter to block commonly used password patterns and compromised passwords, disable #NTLM authentication and disable RC4 for #Kerberos, disable legacy broadcast protocols like LLMNR and NBT-NS, require mandatory #SMB signing, use Group Managed Service Accounts instead of shared passwords, monitor public data breaches for employee credentials, and crack your own passwords to audit the effectiveness of your password policy and user training!

In case you’re wondering how little old Kitten performs in the tests of the Big Boys…

(And that’s from a development build of a page, not a deployment build so no compressed, live reload script in there, etc.)

Turns out it’s pretty easy to ace such tests when you’re not spending cycles and code doing horrible things to people in your web pages (like tracking their every move and attempting to exploit their behaviour for profit). 🤔

💕

#SmallWeb #Kitten #Domain #Lighthouse #score

Andrzej's C++ blog: The obvious final step

https://akrzemi1.wordpress.com/2023/04/23/the-obvious-final-step/

Discussions: https://discu.eu/q/https://akrzemi1.wordpress.com/2023/04/23/the-obvious-final-step/

#cpp #programming

Recently listened to a podcast that claimed "cleaning up code generated by LLM requires lower skilled workers than writing it". I'd argue the opposite is true. To me debugging is way more skill intensive than writing code. And that doesn't even account for a class of bugs that have no thought and intention behind them.

I swear, some of the same people who say “they/them” personal pronouns are impossible to use and too confusing spent their entire youth playing video games that called the player “they/them” simply because it was a little too hard to code in gender-specific pronouns within production constraints, or include double audio.

I wrote a post about bug reporting

https://www.akselmo.dev/2023/04/16/How-I-Report-Bugs.html

tail calls shipping in v8! (but just in webassembly :) https://v8.dev/blog/wasm-tail-call