New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
the OP has stated at least 8 times that SHA is used to check whether you are entering the same passphrase each time. all encryption is done at your browser end and only encrypted passwords are sent. the encryption happens before it gets sent across the wire.
An insecure hash being sent is still an insecure hash, hashing on the client side won't make weak hashes stronger, just protect from MITM attacks or attacks at the application level.
SHA is not recommended for pass phrases, period. It is a fast hash. You want to be using bcrypt or another safe hashing method.
Hello guys,
The site is down at the moment. I took it down after the hearbleed bug for a short amount of time, but decided to keep it down because I have not been able to spend much time on it recently.
The project will be made open source. I have a busy schedule for the next couple weeks, but expect to see the project in github in about 3 weeks or so. I will update thread / create a new one (if it doesn't let me edit) once i do that.
I will have to modify some parts of the program to make sure it will work on all servers, not just preconfigured ones. This is what will take some time.
As for the whole SHA MD5 debate, i am not going to repeat everything again. If you still don't know how this works, or think it is unsecure, just don't use it.
Awesome! Thanks, @ksubedi!
Great!
It's not really SHA vs MD5 and you already changed your mind and went with SHA, I don't know why you think now it's the be all and end all of security. Ultimately it's up to you but really I don't think you should excuse best password practices just because you're hashing client side, the hash travels the network.
You may get away with SHA etc on a forum but you bet your arse any server admin tool is going to be a target for attacks.
What he said!
Agreed to what he refer to said.
of course it is. that hasnt stopped products like lastpass and keypass from being very successful. what isnt a target for hacks today?
So what's your justification for little to no proper password/hash security then? There is none. People are trusting you with sensitive information, it is your duty to protect that with best practices. My country has very strict rules on data protection as do the EU and lots of other nations. You could be legally liable for not only damages, but improper handling of data too.
where exactly is your issue? when was the last time you cracked aes-256 bit encrypted password? if i wanted to steal passwords from you there are a lot of significantly easier methods.
anyway - as im not a security expert I would like to understand what your issue is with the OPs outlined method.
So because I, an individual, can not crack (brute force) this hash that means nobody can? Of course not, don't be so narrow minded with security. This is important, especially with server login info.
So because there are other holes, this one is okay? Again, no, that is not how to program securely. Patch all holes you know about.
As I have said, SHA and MD5 are fast hashing methods meant to be quick. This makes them unsuited for passwords as you can just as quickly hash random strings or dictionaries and use that as a basis for your brute force attack. They are meant to be somewhat secure as a preliminary measure - e.g., checking file integrity - but they are fast, and designed not to use too many CPU cycles.
BCrypt and other methods are slow hashing which is 'intensive' (by comparison) and much slower. This probably won't effect you with people logging in/out etc but it will add significant time to the attack.
This is just one issue, have a google at "good password security programming" or "good password security " for more information. Many people before you have worked on this issue and come up with good solutions, just use them. The odds are your hashing method that took two minutes to code is probably less secure than the guys who code things like PHPPass as a job/passion with a narrow focus.
Weak security is not acceptable and dangerous, especially when you're handling other peoples data.
Have you finished?
Please add a donation button
He doesnt need to crack anything to know that the mentioned hashing algorithms have been known to be vulnerable in certain cases for quite a while.
I admit I did not take the time to read the entire thread, so I cannot comment on the actual implementation, but I can agree with @AThomasHowe as far as simply relying on the mentioned algorithms for a security critical environment is concerned.
Have you even read the thread?
Most of it, did you read my posts? Where did you take issue in what I said?
You must've missed the critical part where he changes from SHA and MD5 to AES-256.
keybase.io solved the problem with https://keybase.io/triplesec/
@0xdragon Really, he changed from Secure Hashing Algorithm to Advanced Encryption Standard, a reversible process? He's storing server login information using AES, SHA is being used for login tokens.
But that would mean the entire application logic was changed (as these are completely different things).
So before the data was irreversibly hashed (how could it be then accessed later?) and now its encrypted on the client side the sent to the server?
If you don't like it, don't use it. That simple. Honestly, I don't see how your comments are constructive in any way.
You don't see how information about how to specifically strengthen security based on the superficial information provided is constructive?
Is it more or less constructive than you trying to call me out and brushing it off? Just wondering.
This is someone who works for three providers who doesn't know the difference between a hash and encrypted data... but yeah, my comments are a cardinal sin.
Here I agree.
Here I do not.
@AThomasHowe has every right to criticise a potentially vulnerable application which is advertised and supposed to carry highly sensitive information.
The constant mixing of terminology between hashing and encryption doesnt make it look better either.
Let me tell you something. It is, currently, impossible to brute force SHA-512 with a random salt for each user. You can't use rainbow tables because you don't have the salts.
"The main reason you want your hashes to be different, is that otherwise people can reverse-crack hashes with so called Rainbow-tables. The original password belonging to a Sha1, MD5 and such, hash, are hard to find: with pure computer power it is possible. However, simply generating a list of all words known (and its variation) and creating a hash for each such word is is simple. Resulting in so called rainbow-tables where one can look up the password that goes with an (unsalted!) hash."
So if he's done the salting correctly (mt_rand or a similar "more random" number generator) the security of this system is very high.
In my country legally it's not good enough to only be able to keep data safe until the day it's broken when better and more proven methods are known.
I could crack a password first try or on the infinity+1st time when you run a random brute force attack, it's random. What about on the off chance it happens? What about in the future when we have quantum computers or thousands of highly clocked cores and fast GPUs? Why even risk it when people who have been paid money and dedicated a lot of time to evaluating good password security.
Why are you so against changing a few lines of code to be in line with best practice? Again, you work for 3 providers, can't you see why this is important?
In that case, you probably cannot rely on any form of encryption except paper stored in a room deep underground with armed robot drones protecting the top and only you can access the elevator down.
Don't drag the providers I work for into this, it has nothing to do with it. I can see your angle, however it looks to me like you're being incredibly future-paranoid. If you like, once the source is released, you can fork it and make it as secure as you like. How about that?
Now you're just being sarcastic because you're actually the one with nothing constructive to add. At first you tried to say I didn't read the thread when you got the details wrong, then you tried to tell me he swapped hashes for encrypted data and now you're being petty mixed in with telling me it's okay because at least as of right now SHA is secure, unless the attacker is one in a billion million lucky.
I would probably just stop personally.
I am just saying, you should have some technical know how no? Maybe you should just stop talking if you're being proven wrong with your employers links in your signature. You should be future paranoid when you're hosting a public facing service. Again, I was using your implied experience as you work in the industry to know this. Hackers are a serious threat to any holes in software.
I could, that's not an option now though is it? And I don't see how me suggesting something to strengthen it is hurting unless I am wrong about it, which you don't seem able to refute.
Also, please stop editing your posts and adding paragraphs. it makes it kinda hard to reply.
I'll edit and be sarcastic as much as I like, thanks. It's not one in a billion lucky, it's one in a billion trillion, probably more.
And why can't you fork and edit it yourself?
Also, I don't know if you've noticed, but I work for support and sysadmin. I'm not a developer.
@0xdragon I said please. But it was a request and not an order, so you're free to ignore it.
Also, it's going to be open source, it's not right now. I guess your comprehension skills are still a little fuzzy.
I guess yours are even more fuzzy. Go and read my last post.