38
Skayo
6y

Checked the GitKraken save files for fun (kind of a hobby) and oh well.... what a wonder:
They store your fucking GitHub access token in "plain text" in a hex file as you can see in the image.
I checked the token and it works. Wow.
Good job GitKraken ✔
That happens when you're closed source...

Comments
  • 2
    Unfortunately the image is blurry... Here's a high quality version: https://s22.postimg.cc/iel56kdtt/...
  • 19
    Um, I'd delete this ASAP because now we all know your github api token
  • 1
    Of course your GitHub account wont be the target of attackers, but it still hurts me :(
  • 8
    <@Alice> <@j4cobgarby>

    I'm not that stupid...

    Of course I replaced the token with an automatically generated string.

    But you can try if you want :)
  • 4
    Started gitkraken once, then my laptop exploded from all that load
  • 4
    <@Alice>

    You know nothing!!!
  • 4
    Well, how *are* they supposed to store it?
  • 6
  • 9
    Haha next patient is FileZilla. FTP passwords are "encrypted" in base64...

    CAN DESKTOP APPLICATIONS FUCKING FINALLY PROPERLY ENCRYPT SHIT FFS
  • 8
    @j4cobgarby Encrypted. Seems like a logical choice, but you can't set a password for that application. Encrypting with a standard key doesn't make sense either.
  • 2
    @PrivateGER I'll have to think about that one, hmmm..
  • 1
    <@PrivateGER> <@j4cobgarby>

    One way, I just thought of, could be encrypting the password/token with various things that only exist on the users computer. Like file paths and stuff.

    Look here:

    https://howtogeek.com/70146/...
  • 8
    @Skayo Then literally anyone could reverse that algo and it'd be just as bad as plaintext.
  • 0
    <@PrivateGER>

    Updated the comment.
  • 0
    <@Alice>

    I never developed a desktop applications that requires passwords
  • 0
    <@Alice>

    I guess you're right :)
  • 3
    Btw DevRantron does store your devRant API key in plain text as well.

    <@tahnik>

    I suggest encrypting your save files with the mac address and machine-uuid as pepper. Like here:

    https://github.com/michaeldegroot/...

    Adds a bit of security at least...

    I don't have to remember you that you're users are a bunch of security-concerned developers :)
  • 0
    <@Alice>

    You're right but I gotta say that the config files for my projects are not as important as for example my FTP passwords or my GitHub Account!
  • 1
    <@Alice>

    Another good point. Dammit!
  • 12
    There's no point in "encrypting" oauth or api tokens, as long as these can be automatically decrypted again. Using client info doesn't change that at all, because anyone who can get hold of the config files or similar can also just make a dump of the system information. A file tree would take a second more, but is still very doable.
    Storing it in anything else than in plain is just obfuscation that can be undone, the easiest way would be to attach some sort of debugger and hook into the function that uses the token. Dump the variable and you're done. Or pull a memory dump etc.
    It doesn't matter, if you start it, there's a way to get the token out
    Also that's why you can easily revoke and / or rate limit / restrict oauth tokens
    You can spent a lot of time and money making the process harder, or you define a compromised machine as doomed anyways and focus on the things you actually can control
  • 7
    No amount of encryption or encoding can protect creds in a config file. Because the key must be stored on the PC. If you can read the config, then you can find the key and decrypt. Less easy but no more secure. The real solution is use a key chain or an HSM.
  • 4
    Add a password to the application and proceed as normal. As long as the user doesn't store the password on the same machine, you're good.

    Anything else is just reversible obfuscation, as others have pointed out.
  • 2
    Generally, no desktop application is secure.
    A memory dump reveals it all.
  • 3
    @Root exactly. That's why I said "auto a decrypt". If you encrypt with a key that's provided on demand, eg loaded from usb or entered by the user and otherwise detached from the pc, the information should really be safe. Except when the app is running and loaded the decrypted stuff into memory, as @PrivateGER said a memory dump would fuck you over
    There even where experiments where they rapidly frosted memory, removed it from the host and kept it frosted over several hours and later revealed part of its contents when heated up again
  • 3
    You all know this shit is in your computer right?
    So it is not about how secure the software is, it is about how secure your computer is.

    Software needs to save sensite shit in your computer, most of the time you don't even know where, but you can be sure you have it somewhere.

    So stop wining, secure your computer.
  • 1
    @Skayo as others mentioned, I don't see the point of encrypting the token.
  • 3
    @Skayo yea honestly its not really worth to encrypt or encode in any way the token. The token actually IS it's own security mechanism. It allows the app to perform what it needs WITHOUT storing actual login creds. It's generated and not user created, unique, and easily revoked.
Add Comment