🅿🅸🆇🅴🅻 @ 314xel @lemmy.world

Posts

3

Comments

97

Joined

2 yr. ago

I want this as a painting on my wall

Not to brag by any means, but english isn't my first language I knew all of the above.

While I find your implants path very interesting, impressive and Cyberpunk worthy, I would't use any externally accessible keys / fobs / etc myself. I wouldn't want someone to unlock my stuff while I'm sleeping. Same reason I avoid face detection unlock. My mind is the best safe out there, I can memorize a very lengthy passphrase and have no problems typing it.

If on Linux and need automatization, GnuPG works, and you can use RSA keys. It's slower than symmetric for large files, but I had success encrypting several tens of GB database backups with a 2048 bit key with no issue. The higher key length you go, the slower. But it has the advantage that you only need to keep the public key on the machine you are encrypting on, and keep the private key safely stored away for when you need to decrypt. Unlike for symmetric, when if you need repeatable / automatized encryption, and you'd store the key in a config somewhere on the same machine in plain sight, and because it's also used for decryption, when leaked you're done for.

Normally you would go with symmetric and generate a good, random AES key each time you encrypt, use AES for actual encryption which is very FAST, and encrypt just the AES key with RSA / asymmetric. This complicates scripts a lot and you end up with 2 dependent files to take care of (the target encrypted file and the file with the encrypted AES key). But this is the sane way of doing it because asymmetric isn't ment for large data lengths (not just because of slow speed). HTTPS and SSH work the same way: asymmetric for key exchange handshake (through public certificates), symmetric for the actual communication while oftenly changing the key.

If no automation is necessary, use VeraCrypt containers. You can keep multiple files in a container. You have several symmetric algorithms to pick from and you can control the number of iterations for key derivation. Debatable as to the added security, but you can also choose to chain up to 3 algorithms in your preferred order.

The above covers the tools and somewhat the algos. For key lengths, see here. I wouldn't go with RSA lower than 4096 these days, elliptic curves is preffered (256 bit +), or AES 256+ in CTR mode. And I'd stay away from lesser known / scrutinized algos.

As others have stated, any recommendation depends on your threat model, how powerful and resourceful are the bad actors you are trying to protect from, how often you need to encrypt, how often to decrypt, the time span for which you need to protect the file, etc.

The rush on getting it working the first time is 👌

That's so true, but what I think keeps us hooked in the game are the failures, the figuring out the "why"s.

Reading as a kid about virus analysis and how they work in a short column in a... newspaper. Yeah, they even listed full Windows Registry paths. Didn't know what HKEY_LOCAL_MACHINE was, didn't own a computer, only knew about some DOS commands, but I knew I wanted to be able to do that job and decompile stuff (whatever that ment) and see how it worked. Just like dismantling (and ultimately destroying) toys to see the inner workings.

After finally owning a computer and being bored by the few games I had on Windows 95, being limited to Notepad, Internet Explorer (without an internet connection yet; or was it Netscape Navigator?) and Paint (in which I sucked, lacking any artistic talent), when I learned that I can just type stuff in Notepad, I borrowed a book about "programming" in HTML. Then Pascal, the pinnacle being a simple XOR encryption program, with a god damn white on blue "windows" interface with buttons (a la Midnight Commander). Writing TRIVIA "scripts" for mIRC channels made us gods. Then Delphi naturally followed, making my own tool to track how many hours I've spent on dialup a month (yes, internet was very expensive) while listening to 80's music on Winamp. Nothing was more interesting than that. Then got a job and out of a sudden started making my own money by writing Delphi code. Up until then I wasn't really aware that my passion would also bring food on the table. The rest is history.

Programming in those days felt unreal. Felt like The Matrix. I knew that what I want to do for the rest of my life is look at text on a screen, hit CTRL+F9, see a crash, set some breakpoints, and ponder around the room or while taking a piss about what went wrong and how to solve it. I'm no Einstein, but I understood why science people dedicate their lifes to their work and disregard completely their social life.

Deleting my social media accounts, migrating from yahoo/google mail, using a password manager, using an ad blocker, frequent backups, all kinds of scripting automations for work, Plex, home automation, learning to fix stuff around the house by myself (some plumbing, some electrical, whatever is safe and easier - it's hard to come by a good, available specialist these days).

That's the idea. It's illegal for Amazon to fire people for not wanting to return on-site, so they do the legally allowed minimum to condition promotions based on that. Legal, but still shitty. They hired a ton of remote (by contract) workers during the pandemic and made a shit ton of profit, now they don't know how to get rid of them without a severance package.

My take: actual, hands-on programming is way more rewarding than reading and watching tutorials.

I learned a lot at work (80% still self-tought, rest from interaction with other teams and other people better than me and with greater experience), and it usually came from needing to make my job easier, not to please the clients or management (scripting and automating things, Linux, DevOps, etc).

The other part through personal projects (again, out of need). You need to take on a project with real use to you. And you get to use the latest frameworks / technologies which you might not at your workplace, depending on the company. Working on personal projects will give you a different kind of fulfillment and will keep you remember that you love to code. Work is work, play is play.

And last, contributions to public, open-source projects. You need to read and understand other people's code, get familiar with Github, write clean, documented code and respect the standards for the project. It will help you in the long run, and you could also add something to your CV.

As for the actual things to learn, don't get stuck on learning just the framework, which does a lot for you out of the box by running commands or calling packages. Try to go in-depth in a programming language and play with the bare-bones, learn the intricacies. Learn for example how code runs and where. I have colleagues still thinking that queues are magical and asynchronous, they write a few lines of code and just work when deployed, without any actual knowledge of the architecture of the system they run on, this leading to no thought in optimization and speed of their code. Or they use the ORM exclusively, which, again, doesn't help when shit hits the fan and you need to debug and optimize for bulk processing.

Also, learn a bit about cryptography and cyber security, even if only for yourself as a hobby. This is where I see a lot of developers lacking, to the point that most don't know the difference between hashing and encryption. There is no project nowdays in the universe where security doesn't matter.

The difference between a mediocre programmer and a good one might not be obvious during an interview, but they will show during the trial period.

Don't buy makeup, buy yourself some backup.

Tanks for this, first time I learn about Rosie, seems promising.

Youtube wantses, Youtube don't getses. Just like Gmail wantsed and I moved to another email provider. They want the money to stop shoving the ads, but still keep the tracking going. Well, I'm the product or the customer, I can't be both.

It depends on how the password is stored / KDF used (what type of hash, salting, bcrypt, etc).

Judge for yourself if it's an old website or old piece of software that might use (god forbid) MD5. Since one would not normally know that, I'd go with 20 (good, cryptographically) randomly generated upper/lower/digits if using a password manager, or 40ish characters passphrase if you need to remember and/or easily type it. Add some punctuation / special chars (spaces, commas, dots, paranthesis, etc) if it's an important masterkey (ie password manager key, encrypted container, etc) and you have decent typing skills.

Some shitty sites / routers don't accept certain special characters hence go with upper/lower/digits as standard but use longer lengths (if the shitty site allows you and doesn't limit that too). Limits to what a password should contain and/or length limits would be a sign of lazy programming and poor password management, so treat them as unsecure from the get-go (yes, even big names like Oracle have piss-poor security or lazy implementation). Good programming nowdays shouldn't have those limits, as user input sanitization / injection protection exists, and hash functions have a fixed length no matter what the input length is.

Also very important, don't reuse passwords for online accounts. Hence a password manager remembering them for you. There are still websites storing passwords in plain text. You wouldn't want your local pizza hut know or leak your email password by being hacked.

Just to add up, the "session" cookie is a special case for the browser which identifies them as such, and handles them as temporary because usually it expires in a few hours. Also, they must have an expiration, and it clears them as soon as you close your browsing session no matter if they expired or not.

Not a "youtuber", but Jason Stephenson - Floating Amongst Stars might help you.

Won't metal do damage / scratch a glass surface? Is it safe?

I think the point was universal dongle with universal BLE / radio protocol. It could still have different encryption schemes and keys for each device / manufacturer by upgrading / installing drivers (so in software), but at least the radio packet protocol would be the same which would keep the hardware universal. Kind of like how smart home hubs (WiFi +/ Zigbee +/ Bluetooth +/ 433MHz / etc) work.

But we all know how creating a new "universal" protocol goes from experience (ie USB "standards").

We return / display the translation key name if no translation is available for that language, including for the default (English).

Also, on dev / test environments we can enable a config (.env) setting to append the text " [UNTRANSLATED]" to every value that doesn't have a translation, as they're easier to spot in the website / interface.

I'm talking about a PHP /Laravel project so it was easy to override the default translation engine behaviour.