2

I have a text document with all my usernames and passwords in it sitting on my desktop. I decided to spend a couple hours making that more secure. I wrote a program for the purpose. It takes a password and a file, SHA-512s the password and adds each byte of it to the file in 64 byte chunks. It subtracts to decrypt. I realise that this falls apart if two hashes sum to 256 for every byte and that this is also only brute-forceable if you know what to expect. Are there any other security flaws?

Scruffy
  • 123
  • 5
  • How is the password decrypted after the hashing? – schroeder Feb 07 '15 at 00:09
  • It's not. The encryption and decryption both need the same password. – Scruffy Feb 07 '15 at 00:41
  • the way you've written your process is confusing, I've read it several times and I still don't understand – schroeder Feb 07 '15 at 00:56
  • wait, you're XOR'ing the 'encryption' password with your text document? – schroeder Feb 07 '15 at 00:59
  • 2
    This is a Vigenere cipher. Use modern encryption. There is nothing you get with your scheme vs. AES-128 in GCM mode with a key derived from the password using PBKDF2 with appropriate work factor. – cpast Feb 07 '15 at 01:31
  • Heck, use an encrypted rar file? – schroeder Feb 07 '15 at 02:06
  • Schroeder, would you like some sample code, as there is no direct XOR involved? Furthermore, although I've never seen one working, there are RAR password brute force attack programs. – Scruffy Feb 07 '15 at 02:17
  • 1
    @TheJavaNot-So-Pro Addition has no relevant security differences from XOR. XOR is adding in chunks of one bit; you're adding in chunks of 64 bytes. There's no practical difference. Use proper crypto. For brute-force programs, there's a brute-force program to attack UNIX password hashes made with bcrypt and scrypt. The existence of said program doesn't mean it's likely to actually work on a password in a reasonable amount of time, and it's trivial to write a brute-force program that runs way, way, way faster on your scheme. – cpast Feb 07 '15 at 02:41
  • I'm also assuming that your program to do this encrypting will also be secure and can't be reverse engineered? – schroeder Feb 07 '15 at 03:29
  • "this is also only brute-forceable if you know what to expect" -- it's likely that you use some type of script or program to decrypt the file, so an attacker can look at that program to figure out how to reverse your encryption. but worse, if an attacker knows your password or some other plaintext in the file (like a username or web site name), he can use that knowledge to reduce the search space for his brute force attack. – Johnny Feb 07 '15 at 05:27
  • @cpast's answer covers it completely: never ever ever roll your own crypto system that depends on keeping your special sauce secret. Use the standard, published and peer-reviewed techniques. It isn't an accident that they have become standards: they work, and are as secure as is reasonably possible. – Dave Mulligan Feb 07 '15 at 08:00

2 Answers2

6

this is only brute-forceable if you know what to expect

Stop right there. What you're describing is security through obscurity. You're betting that an attacker won't be able to know or guess your scheme. This is a really, really, really terrible assumption. It's an alluring one, but time and again it's been proven wrong. Any proper security scheme must work even if the attacker knows the system you're using; an attacker who knows everything but your password should not be able to practically attack the system.

So, throwing out the assumption that an attacker doesn't know your scheme: The security is frankly terrible. First, it's very simple for an attacker who learns part of the plaintext to use that to recover other parts, because you add the same thing to each 64-byte chunks. An attacker who gets one password of yours can see what having it in one section of the ciphertext means; specifically, if they assume it's at position X, they can subtract it from the ciphertext and get a potential part of the keystream, then try that keystream elsewhere.

Second, your program is quite vulnerable to brute-force. SHA-512 is an extremely fast hash. Fast hashes are great, in general -- they mean your crypto is faster, which means you have less overhead, which means you're more likely to be able to use crypto everywhere with acceptable performances. But they're terrible for passwords, because passwords are almost invariably low-entropy. With SHA-512, an attacker who recovers the file can brute-force passwords extremely quickly. Hashes used for passwords need to be slow: the thing you're hashing is low-entropy, so your hash must take a while to run to make this slower. A GPU can compute millions of SHA-512 hashes per second; doing your decryption is also fast, so this is not suitable to resist brute-force.

You should not use this scheme. Rather, you should use proper cryptography. If you were to build it yourself, this would look like an actual secure cipher (e.g. AES in an appropriate mode), with the key derived with a slow function (e.g. PBKDF2). Can your scheme work? Well, if your password is very high-entropy, possibly -- at the extreme level, if your password is a 128-bit truly random string, you may as well use that directly as the key to AES. But your password is likely weaker than you think, so you should just use a slow hash.

However, you should not do that either. Cryptography is really hard to implement properly. Where possible, you should use well-tested secure systems instead of coding something yourself. For instance, you could use GPG to encrypt the file; you could also use a password management tool (I'm pretty sure there exist such tools that don't even store encrypted data on the cloud, but are entirely local). Don't implement your own system except for practice; if you do, don't use the scheme described here.

Looking at your other question, you seem to still think you can effectively hide your scheme from an attacker and rely on "no, they won't figure out what I'm doing." So, here's something beyond the (fully sufficient) "security by obscurity isn't effective:" The only reason to care about an attacker decrypting your file is that they already have the file. That means you failed to keep a file on your computer secure. Your program is also a file on your computer. Why assume you can keep that secure, even if the file containing the passwords isn't?
Community
  • 1
cpast
  • 7,263
  • 1
  • 30
  • 35
3

You're encrypting your document with a polyalphabetic cipher (the best-known of which is the Vigenere cipher). Techniques for breaking these have been known since the mid-1800s. Yours is particularly vulnerable since the number of alphabets (64) is fixed, and the alphabets are simple rotations (as opposed to shuffles).

If you really want to protect your passwords, use modern encryption as implemented by someone who knows what they're doing. Either get a password manager, or use file-encryption software.

Mark
  • 34,513
  • 9
  • 86
  • 135