I'm working on a project with a teacher to overview the project at my school to be responsible for the confidential student data...

Teacher: How are we going to authenticate the kiosk machines so people don't need a login?

Me: Well we can use a unique URL for the app and that will put an authorized cookie on the machine as well as local IP whitelisting.

Teacher: ok but can't we just put a secret key in a text file on the C drive and access it with JavaScript?

Me: well JavaScript can't access your drive it's a part of the security protocol built into chrome...

Teacher: well that seems silly! There must be a way.

Me: Nope definately not. Let's just make a fancy shortcut?

Teacher: Alright you do that for now until I find a way to access that file.

I want to quit this project so bad

A Bank Account Number is like a public encryption key. Any random person needs it to send me money. Why does it seem like banks treat it as a secret or even use it to confirm my identity? It's literally printed in plain text on every check.

Api key and secret on js variables...

Today’s DevOps public service announcement... don’t test your server provisioning scripts locally. Especially when this gem is in there:

rm -f ~/.ssh/id_rsa
echo ‘vault secret/ssh_key’ > ~/.ssh/id_rsa

Well, I no longer have my key, but the script works! I’m sitting with a very locked down server key

When a bunch of unit tests start failing locally because the AWS secret key got rotated.
oh wait...
THOSE AREN’T UNIT TESTS!!!
Unit tests do not depend on any external system, that includes AWS...
AAARRGHHHHH

Stupid pipeline bullshit.

Yeah i get it, it speeds up development/deployment time, but debugging this shit with secret variables/generated config and only viewable inside kubernetes after everything has been entered into the helm charts through Key Vaults in the pipeline just to see the docker image fail with "no such file found" or similar errors...

This means, a new commit, a new commit message, waiting for the docker build and push to finish, waiting for the release pipeline to trigger, a new helm chart release, waiting for kubernetes deployment and taking a look at the logs...

And another error which shouldn't happen.

Docker, fixes "it runs on my machine"
Kubernetes, fixes "it runs on my docker image"
Helm, fixes "it runs in my kubernetes cluster"

Why is this stuff always so unnecessarily hard to debug?!

I sure hope the devs appreciate my struggle with this... well guess what, they won't.

Anyways, weekend is near and my last day in this company is only four months away.

Over heard while watching a tutorial

"The secret key is really secret"

Trying to use authenticate a JWT token from an Azure service, which apparently needs to use Azure AD Identity services (Microsoft Entra ID, Azure AD B2C, pick your poison). I sent a request to our Azure admin. Two days later, I follow up, "Sorry, I forgot...here you go..."
Sends me a (small) screenshot of the some of the properties+GUIDs I need, hoping I don't mess up, still missing a few values.
Me: "I need the instance url, domain, and client secret."
<hour later>
T: "Sorry, I don't understand what those are."
Me: "The login URL. I assume it's the default, but I can't see what you see. Any shot you can give me at least read permissions so I can see the various properties without having to bother you?"
T: "I don't see any URLs, I'll send you the config json, the values you need should be in there."
<10 minutes later, I get a json file, nothing I needed>
<find screenshots of what I'm looking for, send em to T>
Me: "The Endpoints, what URLs do you see when you click Endpoints?"
<20 minutes later, sends me the list of endpoints, exactly what I'm looking for, but still not authenticating the JWT>
Me: "Still not working. Not getting an error, just that the authentication is failing. Don't know if it's the JWT, am I missing a slash, or what. Any way I can get at least read permissions so I don't have to keep bugging you to see certain values?"
T: "What do you need, exactly?"
Me: "I don't know. I don't know if I'm using the right secret key, I can't verify if I'm using the right client id. I feel like I'm guessing trying to make this work."
T: "What exactly are you trying to get working?"
<explain, again, what I'm trying to do>
T: "That's probably not going to work. We don't allow AD authentication from the outside world."
Me: "Yes we do. Microsoft Teams, Outlook, the remote access services. I can log into those services from home using my AD credentials."
T: "Oh yea, I guess we do. I meant what you are trying to do. Azure doesn't allow outside services to authenticate using a JWT. Sorry."

FRACK FRACK FRACK!!

Whew! Putting the flamethrower away.

Thanks devrant for letting me rant.

DO NOT EXPORT GPG KEYS _TEMPORARILY_ AND ASSUME THAT THEY'LL BE IN THE ORIGINAL LOCATION AFTER EXPORT!

I learnt this lesson the hard way.

I had to use a GPG key from my personal keyring on a different machine ( that I control ). This was a temporary one-time operation so I thought I might be a smart-ass and do the decryption on the fly.

So, the idiotic me directly piped the output : `gpg --export-secret-key | scp ...`. Very cool ( at the time ). Everything worked as expected. I was happy. I went to bed.

In the morning, I had to use the same key on the original machine for the normal purpose I'd use it for and guess what greeted me? - *No secret key*

*me exclaims* : What the actual f**k?!

More than half a day of researching on the internet and various trials-and-errors ( I didn't even do any work for my employer ), I finally gave up trying to retrieve / recover the lost secret key that was never written to a file.

Well, to be fair, it was imported into a temporary keyring on the second machine, but that was deleted immediately after use. Because I *thought* that the original secret key was still in my original keyring.

More idiotic was the fact that I'd been completely ignorant of the option called `--list-secret-keys` even after using GPG for many years now. My test to confirm whether the key was still in place was `--list-keys` which even now lists the user ID. Alas, now without a secret key to do anything meaningful really.

Here I am, with my face in my hands, shaking my head and almost crying.

9000 internet cookie points to whoever figures out this shit:

I'm trying to import a secret gpg key into my keyring.
If I run "gpg2 --import secring.gpg" and manually type each possible password that I can think of, the import fails. So far, nothing unusual.
HOWEVER
If I type the same passwords into a file and run:
echo pwfile.txt | gpg2 --batch --import secring.gpg
IT ACTUALLY FUCKING WORKS

What the fuck??? How can it be that whenever I type the pw manually it fails, but when I import it from a file it works??
And no, it's not typos: I could type those passwords blindfolded from muscle memory alone, and still get them right 99% of the time. And I'm definitely not blindfolded right now.

BUT WAIT, THERE'S MORE!!

Suppose my pwfile.txt looks something like this:

password1
password2
password3
password4
password5
password6

Now, I'm trying to narrow it down and figure out which one is the right password, so I'm gonna split the file in two parts and see which one succeds. Easy, right?

$ cat pw1.txt
password1
password2
password3

$ cat pw2.txt
password4
password5
password6

$ echo pw1.txt | gpg2 --batch --import secring.gpg
gpg: key 149C7ED3: secret key imported

$ gpg2 --delete-secret-key "149C7ED3"
[confirm deletion]

$ echo pw2.txt | gpg2 --batch --import secring.gpg
gpg: key 149C7ED3: secret key imported

In other words, both files successfully managed to import the secret key, but there are no passwords in common between the two!!
Am I going retarded, or is there something really wrong here? WTF!

Accidentally pushed AWS IAM access and secret key to repository defined within application.yml file in code, immediately i got a mail from AWS warning me that my access and secret keys are now exposed with instructions how to rotate this key and secure it. How the fuck do they know?

Made my day.

Need to setup some VMs and the users refuses to give me the public key.

No words!

Eurgh, sometimes there's just *no need* to change stuff between major API versions - such as the AWS secret key being read from aws.secretKey in v1 of the AWS Java SDK, and aws.secretAccessKey in v2.

Just spent way too long to admit wondering why the secret key wasn't being picked up before realising the above. Doesn't help we have multiple projects on differing major versions of the SDK either.

So in Seahorse (the Gnome secret manager) deleting the OpenSSH key doesn't just remove an identity from agent, it actually deletes the keyfile.

I should've treated that scary confirmation message more seriously.

Also, my obsessive full disk backups every Monday are totally worth the time.

I need a help salesforce guys,
I am trying to automate Salesforce sandbox creation, then copying the client secret and key from an app and then use those credentials for some application.
Sandbox creation and deletion is done, but I am not able to get how should I fetch client credentials. I searched internet, and I only find gui method : login, select app, select view, get credentials.
At last I wrote a shitty selenium script but I don't have faith in this approach.
If anybody can give me insight, It would be great help.