Two Factor authentication is a plugin similar to xAuth for bukkit. It allows players to secure their account by forcing two factor authentication for their account. They can choose between either using a Google Authenticator applicable application, or by using secure password storage. The password storage used is SHA3. This is specifically chosen because Plaintext is not secure at all (yes I've seen some people doing this), MD5 is so so broken (;~; I weep how tons of application still use this. ;~;), and so this leaves SHA. There's SHA1, SHA2, and SHA3. They're all about the same "difficulty" to implement. So since all are about the same for implementation we might as well go for the most secure. (SHA1 is insecure by Military standards, SHA2 is probably close cause of the similarity to SHA1) so might as well go to SHA3!
You can view the progress for it on github here. (Yes I’m aware it needs a lot of fixes, the DEBUG version is meant to be easy to DEBUG so it’s quite ugly).
I don’t follow your logic. A majority of applications (including many 2FA apps) still use SHA-2 because it is proven and has been used for around a decade. No major vulnerabilities have been found for SHA-2. In cryptographic terms, the algorithm selected for SHA-3 is young and more dangerous to use, regardless of how secure it looks.
Also, I recommend against you implementing an algorithm like this for production use cases. Use one of the dozens of existing implementations in Java for SHA-2 in projects where other people rely on you. Implementing cryptographic algorithms are great for personal use and growth, though.
@gratimax
I never said SHA2 was insecure, I just said since SHA2 is just as easy to implement as SHA3, why not go with SHA3 which has less clashes. (The part about it probably will get cracked soon due to similarities was just my opinion). SHA-3 passes NIST tests, and while younger. It is not “more dangerous” it has less clashes than SHA-2. True there could be unforseen clashes later, but with diligence, and until that happens (not likely) it is techincally more secure at this point in time.
BouncyCastle’s SHA3 meets all the standards of NIST, and works beautifully. I’m am not the implementor, as your right. Implementing yourself is good for practice should not be used in production. Back when I was into network security I had to have that talk a lot.
@Zwei
Directly from the keccak developers:
[code]
"I misspoke when I wrote that NIST made "internal changes" to the algorithm. That was sloppy of me. The Keccak permutation remains unchanged. What NIST proposed was reducing the hash function's capacity in the name of performance. One of Keccak's nice features is that it's highly tunable.
I do not believe that the NIST changes were suggested by the NSA. Nor do I believe that the changes make the algorithm easier to break by the NSA. I believe NIST made the changes in good faith, and the result is a better security/performance trade-off. My problem with the changes isn’t cryptographic, it’s perceptual. There is so little trust in the NSA right now, and that mistrust is reflecting on NIST. I worry that the changed algorithm won’t be accepted by an understandably skeptical security community, and that no one will use SHA-3 as a result.
This is a lousy outcome. NIST has done a great job with cryptographic competitions: both a decade ago with AES and now with SHA-3. This is just another effect of the NSA’s actions draining the trust out of the Internet."
[/code]
There was FUD spread, but it is not actually true.
The idea is awesome, but I think it’s a bit exaggerated. It’s not like it’s a email account or a repository with a lifetime’s work (e.g. GitHub), it’s a simple game. A password will suffice in most cases.
However, this is great for admins and OPs for obvious reasons!
So this is my way of saying that it would be nice if each user could define if they want to use this functionality or not
True it will, but there are people who like the sense. I agree, the chances of it being a problem is next to nothing. (Which is why by default it is optional for every single player, and I believe that’s the way it should stay).
So to answer your question YES! it is not required to set up a TFA on an account which you do not want it.
Please, please do not use a fast hash for password storage. Especially not Keccak. Keccak only uses boolean operations, so it’s insanely fast. Even more so on a FPGA.
What you want is scrypt, bcrypt, or PBKDF2 (in order of preference).
Scrypt is the best choice, as it’s best computed on a PC - aka, what you’ll be running the legitimate software on.
Bcrypt and PBKDF2 are well-proven and used a lot though, so if you want a proven algorithm over a less-proven-but-theoretically-more-secure algorithm, go with one of them.
Otherwise, this seems like it will be a nice plugin to have for securing admin accounts. Good idea.
I am aware of the possibilities of a Fast HASH. I am aware of PBKDF2, and SCrypt, how it is the best suited for the job in most cases. (As I use SCrypt for all my website storage). Yes I am aware Fast Hashes should not generally be used, and I do plan to add those algorithims later on, and switch those to default.
Why did I choose SHA3 when it shouldn’t be the one for the job in most cases? I started with SHA3 is because some servers have 512mb, or 1/2GB of ram. Computing BCrypt (which is better, but why would you choose this instead of PBKDF2, or SCrypt?), SCRYPT, or PBKDF2 will seriously halt those servers.
I am aware there are much better algorithims, for security. As that is what I used to do, and have a huge passion for. It is a Performance/Security tradeoff. One that I hate to make, but is required due to the hardware people are running on. (People are still running java 6 even though java 6, and java 7 have both hit their EOL.). I agree it is not ideal
Then let them tweak the parameters? Scrypt, bcrypt, et al are configurable so they can run on any hardware. SHA3, SHA2, SHA1, MD5, RIPEMD-160, CRC32, XOR, etc are all extremely bad ideas for password hashing, period. There is absolutely no argument in your favor for using insecure password storage.
Here is a good cross-platform Java implementation of scrypt. It will use the natives if available. Here is a Java implementation of bcrypt. PBKDF2 is built-in to Java.
If you’re going to use a fast hash, at least use SHA-2 and at least salt it. Salting is basically free and there is no reason not to do it.
I never said It couldn’t run. I said it would “seriously halt these servers”. Which is true it would. They are meant to take up work on the servers. That is where their strengths are coming through. There is plenty of argument for the reason I have chosen it for now, and as afermentioned is planned to make the default SCrypt. The SHA3 is the start for servers running 512MB/1GB/2GB. Which SCrypt, BCrypt, and PKBDF2 will seriously halt.
I do not need implementations of it, as I have already been looking into that though thank you for your suggestions.
See my argument above for not using SHA-2. As SHA-3 has less clashes it is techincally more secure. Keccak is also faster better benifiting those servers. Salting is going to be implemented. SHA-3 with salting.
Also if you say never use SHA-2,SHA-3, etc. Why do you later on recommend it? Again I agree it is not ideal, however neither is running a 512MB/1GB/2GB server. It is a performance/security tradeoff. SCrypt will be the default.
Regardless of passwords, google authenticator is what I use for a few of my accounts, including github. Really excited to see it in a minecraft plugin. I was considering taking the job for lambda when I saw his rant about all the other plugins, but I guess I was just too lazy.
I’m not good in crypto. I talked with a few people on a minecraft engineering server and they all insulted me for trying to use SHA-3 instead of BCrypt. That’s also where I heard of the rumors that NSA was nerfing it to make it easier to break.
(P.S. I do know for a FACT that sha-3 doesn’t have a 512 variant)
Yes and I will use Google authenticatior as my main form here. And I dont have crazy rants, I’m just a super passionate speaker for example I’m mad at no one in this thread, and yes SHA-3 shouldn’t be used in most cases, I just implemented it first, and only for the servers that can’t efficiently run things like SCrypt.
All the talk of SHA3 is great, but it doesn’t look like you’re salting your passwords. You could have the strongest hashing in the world, but if you don’t salt it, it’s trivial for an attacker to compromise (at least some of the) accounts. Wikipedia has more details
Or look at the issue “things to get done”. Seriously everyone in this thread keeps trying to say I’m doing things wrong, and you should learn security. When the fact is I worked in network security for a couple years, and was planning on these things. If they would’ve looked at the github issue, or simply asked they would realize this is far from done.
for example I’m mad at no one in this thread, and yes SHA-3 shouldn’t be used in most cases, I just implemented it first, and only for the servers that can’t efficiently run things like SCrypt.