# Insecure Passwords?



## crashdoom (May 20, 2016)

With the recent Administrator Notice, there's one alarming point to be raised (Okay, there's several, but let's focus on one.)







*Encryption vs. Hashing.*

One of these is a one-way process making it impossible to derive the original password, the other is a two-way process that allows an "authorized user" to obtain the original plain-text password.

Since "Encryption" has been mentioned directly, can the Administration team clear up the confusion and correct their terminology, or explain the complete lack of security?

Yes, it's a really petty thing to ask. But I'd want to know if hackers have my plain-text passwords, wouldn't you?


----------



## CreideikiStormbringer (May 20, 2016)

crashdoom said:


> *Encryption vs. Hashing.*
> 
> One of these is a one-way process making it impossible to derive the original password, the other is a two-way process that allows an "authorized user" to obtain the original plain-text password.


One of those is also what you should _never fscking do_ for password storage, and the other, without other requisite actions is also something you should _never do_ with password storage.



crashdoom said:


> Since "Encryption" has been mentioned directly, can the Administration team clear up the confusion and correct their terminology, or explain the complete lack of security?
> 
> Yes, it's a really petty thing to ask. But I'd want to know if hackers have my plain-text passwords, wouldn't you?


To give those of us with knowledge in the field, would the Admin team please clarify what their password storage method is? Because just saying "they're hashed" could mean anything from "this is worse than being encrypted" to "Oh good, my password is safe."

Because if they're doing straight hashes, then I'd like to remind everyone of XKCD 1286 (the Adobe password leak). Or, as it might end up being called: "Password Crossword V2.0: Furry Edition"

At least with encryption (unless they're using DES or some similarly badly broken cipher, and if they are *WHY!?*) the passwords are safe unless the keys are leaked (which since shell access was got to the server, they probably _are_).

I should hope the site is using bcrypt or scrypt for password storage (as one _should_ be doing in the year 2016), or at the very least PBKDF2 with a large number (10000 or more) of iterations.


Not that I personally have to worry about my password getting leaked, I use a different one for every site.


----------



## Movieaddict (May 20, 2016)

CreideikiStormbringer said:


> At least with encryption (unless they're using DES or some similarly badly broken cipher, and if they are *WHY!?*) the passwords are safe unless the keys are leaked (which since shell access was got to the server, they probably _are_).
> 
> I should hope the site is using bcrypt or scrypt for password storage (as one _should_ be doing in the year 2016), or at the very least PBKDF2 with a large number (10000 or more) of iterations.



I know many sites even don't have keys to decrypt the password. So the password is used in its encrypted form on the site. However the problem with this is an external script or fake login from could gain access to the site if it connects to the right file on the server. That I why having the source code leaked is such a bad thing.

In the end your password is safe but your account on FA is not. With this if you used the pass elsewhere it is lickly safe but I would still change it any wise. Because you just don't know what they got.


----------



## Kragith Zedrok (May 20, 2016)

I have stuck with FA on all fronts, I'm not too happy about security issues... I changed my password the day it went online.


----------



## AsheSkyler (May 20, 2016)

I just changed mine a day or two ago. I wonder if this means I'll have to change it again?


----------



## CreideikiStormbringer (May 21, 2016)

Movieaddict said:


> I know many sites even don't have keys to decrypt the password. So the password is used in its encrypted form on the site. However the problem with this is an external script or fake login from could gain access to the site if it connects to the right file on the server. That I why having the source code leaked is such a bad thing.


That's... not really possible. There are two kinds of encryption, symmetric (AES, Blowfish, DES, Serpent, Twofish, IDEA, Skipjack, RC4, et cetera) and asymmetric (RSA, Diffie-Hellman, MQV, et cetera). Asymmetric ciphers are used not for message encryption, but key exchange (RSA and DH) and digital signatures (RSA and DSA); meanwhile symmetric ciphers are used for message encryption.

As the names imply, in asymmetric ciphers each end of the system uses different keys, a public and private key used to encrypt, and decrypt the small bit of plaintext being transmitted (a key for a symmetric algorithm, or hash of a message for a signature; though signatures are special cases, where the signature is encrypted with the private key, so that you can decrypt with the public-key to all for verifying the signature). Public key algorithms, to be secure, need _huge_ key sizes. On the order of a 2048-bit RSA key (or Diffe-Hellman key, they're relatively close, mathematically) will last until about 2030, and you'll need a 3072-bit key if you want it to last longer than 2030. For an RSA/DH key to be equivalent in security to a 256-bit AES key, you need a *15360-bit* key (as suggested by the NIST). Creating these keys, and storing the parts that are needed to compute the encrypted password is, to put it lightly, a huge computational load, and a waste of network resources, as you'd be sending the gigantic modulus (i.e. the 2048-bit number) and the public key (often the prime number 65537) to the user to encrypt their password before sending it to the server (or you can do the encryption on the server, but then you're sending the password in the clear, which is a big no-no).

Symmetric algorithms only have one key, used to encrypt or decrypt. Thus the server cannot simply wipe the key after encrypting the password, because it or the user, would be unable to calculate if the supplied password is correct. And at this point, since the key must be stored, you may as well just store the passwords in the clear. And if you throw the key into the server's TPM (where it's relatively safe from compromise) and use the one key for every password... well if you don't pick a good block cipher mode (i.e. if you take ECB mode, instead of _any other of the ones available_) you'll be able to do "Password Crossword" again. Oh, and if you _do_ pick a sensible mode, you still need to pass the password to the server in the clear. And you're _still_ not getting any benefit over a salted hash!

Making sure the authentication goes correctly, there are methods for that which have been solved, e.g. look at the SCRAM method of password-based authentication (benefits of SCRAM are that it prevents man-in-the-middle attacks by having the client check that the server is what it say it is, and the server checks to make sure the client is what it says it is). The server never even sees the password in the clear for day-to-day use, only ever seeing it when you need to set a new one (at which point you and the server are using an encrypted connection via SSL/TLS, right? If not then someone is doing something _wrong_).

In the end, having the source code should not be a problem, period. If having the source code opens you or your site up for attack then quite clearly something is being done wrong. One of the most important lessons learned in cryptography is Kerckhoff's Desideratum (which was something that was stated in *1883*): "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge."
Claude Shannon restated that back in 1949 as the much more terse, and more quotable: "The enemy knows the system."
Granted those are both specifically stated in regards to cryptography, but it applies equally to all sorts of security related topics. But it applies equally to software projects; because if knowing the source means I can break things, what's stopping someone who _doesn't_ have the source from breaking things accidentally? That's why open source projects have better security than closed source. Look at Linux; or even better since we're talking about security breaches and mitigating/preventing them: Look at OpenBSD, which possibly the most secure UNIX-like system currently out there (and it's both completely free, and completely open source to boot). They have a lot of different eyes poring over their code, making sure bugs are fixed, and security holes are patched; and if you look at what the OpenBSD project does for security they have a team of coders going over everything with a fine toothed come for code auditing.


Getting back to the point: _encrypting_ passwords is never a valid or correct method of storing them; either you end up with a false sense of security and are essentially storing passwords in a manner that's only _just_ better than storing them in the clear, or you're creating a massive overhead to replicate the functions of a simple keyed hash function (HMAC-[MD2|MD5|SHA-1|SHA-224|SHA-256|SHA-384|SHA-512]). The correct way to store a password is, in the year 2016, to use a specific password hashing algorithm like scrypt, or bcrypt; or using PBKDF2 with a large number of iterations. The only more secure way to provide user login authentication would be use user public keys, but that's far too complicated for the average Joe user (plus then you run into the issue of: Who generates the keypair? And how can whoever recieves the keypair trust it's from who it says it is?)





Movieaddict said:


> In the end your password is safe but your account on FA is not. With this if you used the pass elsewhere it is lickly safe but I would still change it any wise. Because you just don't know what they got.


Of course, I'll change the password when FA goes out of read-only mode. Especially now that I've heard the site's password and accounting database has been compromised.


----------



## Resua (May 21, 2016)

forums.furaffinity.net: It's Time for Real Account Security

Dragoneer reported they were hashed and salted.  Even if done with MD5, should be reasonably secure if your password was secure (10 digits+, upper, lower, punctuation, and a number.)


----------



## Shaun Dreclin (May 21, 2016)

Resua said:


> forums.furaffinity.net: It's Time for Real Account Security
> 
> Dragoneer reported they were hashed and salted.  Even if done with MD5, should be reasonably secure if your password was secure (10 digits+, upper, lower, punctuation, and a number.)



Sort of off topic but man md5 should be removed from all languages by default, and require some sort of external library to use. It provides the illusion of security to people who are just learning D:


----------



## Resua (May 21, 2016)

Shaun Dreclin said:


> Sort of off topic but man md5 should be removed from all languages by default, and require some sort of external library to use. It provides the illusion of security to people who are just learning D:


Different hashes are just buying time.  GPGPUS are getting faster and faster and faster.  Right now, PBKDF2 is about all you can do to slow them down, and if you wanna be a real jackass, PBKDF2 100,000 deep, stacked with something that cannot be parallelized.


----------



## Gem-Wolf (May 21, 2016)

Ninetales666 said:


> ---REDACTED; quote of removed post---


Ever seen the block option? Shoulda used it


----------



## CreideikiStormbringer (May 21, 2016)

Resua said:


> forums.furaffinity.net: It's Time for Real Account Security
> 
> Dragoneer reported they were hashed and salted.  Even if done with MD5, should be reasonably secure if your password was secure (10 digits+, upper, lower, punctuation, and a number.)


MD5 is, and I'll quote the CMU SEI here, "cryptographically broken, and unsuitable for further use." To describe _how_ broken it is, the attach published by Xie Tao, Fanbao Liu, and Dengguo Feng in 2013 can find a hash collision is _less than a second_ on a modern PC.

So yeah, even salted MD5 would be a bad idea for password storage. In fact "just" a salted and hashed password alone is not good enough. Because people are working on hardware and algorithms to compute hash collisions easily. Just look at BitCoin mining; which is entirely about finding hash collisions.




Shaun Dreclin said:


> Sort of off topic but man md5 should be removed from all languages by default, and require some sort of external library to use. It provides the illusion of security to people who are just learning D:


Being a C programmer by hobby (and trade, sort of); and a Visual Basic programmer for work (Microsoft Office can *<REDACTED>*): What languages have MD5 as a part of them!?

Anyway, in the land of Windows, as long as you have XP or newer your system supports modern hash algorithms by way of the Microsoft Cryptographic API. (It also supports _old_ algos as well, so you can still use MD5, or worse, _MD2_, instead of SHA-256, or SHA-512.) CryptoAPI is a bit of a pain to use though.




Resua said:


> Different hashes are just buying time.  GPGPUS are getting faster and faster and faster.  Right now, PBKDF2 is about all you can do to slow them down, and if you wanna be a real jackass, PBKDF2 100,000 deep, stacked with something that cannot be parallelized.


No, scrypt and bcrypt, which are specifically designed algorithms for password storage, are better than PBKDF2. This is because, when you get right down to it, PBKDF2 is still based on HMAC with standard cryptographic hashes (the standard implementation is HMAC-SHA-1); thus it is parallelizable. Both scrypt and bcrypt are designed to be significantly more resource intensive, scrypt in particular is "resource hungry" so as to make implementation in custom hardware be difficult, as well as being designed in such a way that the algorithm does take some non-insignificant time to calculate.

The best solution right now is scrypt, followed by bcrypt, followed by PBKDF2 with an - and I'm going to use a highly technical turn of phrase here - _metric arseload_ of iterations (LastPass runs about 100000 iterations) preferably also with a strong "base" hash function (screw your HMAC-SHA-1, we're doing HMAC-SHA-512!). In terms of ease of implementation, simply reverse the list; since PBKDF2 is the long-time established method, and scrypt is relatively new.


----------



## darien (May 21, 2016)

Shaun Dreclin said:


> Sort of off topic but man md5 should be removed from all languages by default, and require some sort of external library to use. It provides the illusion of security to people who are just learning D:



There is so much wrong with this post that I don't know where to start. Please spend some time researching what md5 is and what it is commonly used for (hint: it's not passwords)


----------



## crashdoom (May 21, 2016)

darien said:


> There is so much wrong with this post that I don't know where to start. Please spend some time researching what md5 is and what it is commonly used for (hint: it's not passwords)


Agreed, MD5 should not be removed as it has a multitude of other uses. Though a number of websites sadly still use MD5 for password hashing.


----------



## Shaun Dreclin (May 21, 2016)

I was mostly referring it to being used in PHP and people thinking it's secure enough to hash passwords with. Also was mosly joking, I know md5 has other uses.


----------



## Gregtheslayer (May 21, 2016)

I dont really care much of encryption altough it does provide better sevuritg. For all i care isbthat our password were stolen and sometimes i usebsame passwords for other accounts other than fa. All i want is to know wether my accounts password was stolen so i could change the passwords on my other accounts.

FA should use better decryption devices whilst evalutaing on the security they have.
No offense but im still confused on why they brought their hard drive containing user data to a furcon. It just doesnt add up


----------



## Fordoxia (May 21, 2016)

Gregtheslayer said:


> I dont really care much of encryption altough it does provide better sevuritg. For all i care isbthat our password were stolen and sometimes i usebsame passwords for other accounts other than fa. All i want is to know wether my accounts password was stolen so i could change the passwords on my other accounts.
> 
> FA should use better decryption devices whilst evalutaing on the security they have.
> No offense but im still confused on why they brought their hard drive containing user data to a furcon. It just doesnt add up


They didn't.  An ImageMagik exploit allowed the attackers to gain access to the source code, which they then copied to USB drives, which were distributed at the con.


----------



## Gregtheslayer (May 22, 2016)

Fordoxia said:


> They didn't.  An ImageMagik exploit allowed the attackers to gain access to the source code, which they then copied to USB drives, which were distributed at the con.


oh ok, could they determine what users password that got stolen???


----------



## Fordoxia (May 22, 2016)

Gregtheslayer said:


> oh ok, could they determine what users password that got stolen???


Assume any password made before the site went live on the 18th is public knowledge.

Such is good cryptographic practice.


----------



## Wakboth (May 22, 2016)

Gregtheslayer said:


> I dont really care much of encryption altough it does provide better sevuritg. For all i care isbthat our password were stolen and sometimes i usebsame passwords for other accounts other than fa.


You really shouldn't do that. Like, _really_ shouldn't. It's one of the biggest unforced errors people can do with their passwords.



> All i want is to know wether my accounts password was stolen so i could change the passwords on my other accounts.


The safe thing do to is to assume that yes, the password was stolen. Change the passwords. And make sure you don't reuse the same one!


----------

