|
It doesn't matter. As the code only refers to the interface, you can substitute in any implementation. That's what makes it substitutable and testable.
This space for rent
|
|
|
|
|
So after my last post on this I did some research and now I have a question.
From what I can see the idea is to Hash the password, then store it to the DB. Next, you Hash a string and compare it to the stored value. This is all done on the server where it's most secure.
The part I'm questioning is that it seems that you have to pass the PLAIN TEXT password to the back end to do the comparing.
What's the right way to do this?
Thanks
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
If it's a website, then yes, generally it's a plain-text password that gets transferred to the server - which is insecure but then so is sending a hashed password for comparison!
Provided your login page is SHTML so it's via an encrypted connection, that isn't a problem, because the password isn't transfered over the web in clear, so it's difficult if not impossible to set up a man-in-the-middle attack to access the "raw" password.
Once it reaches the server, it gets salted, hashed, and compared.
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
He could always encrypt the password in order to transfer it, decrypt it after it's transferred, and then hash it to compare with the database content.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Except that means the encryption key needs to be available to the javascript... 
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Joking again?
(That's precisely what HTTPS does.)
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
No, not joking. HTTPS has been proven insecure (there was a big kerfuffle over that realization a couple of years ago), so why solely rely on it? It shouldn't be difficult to set up.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
John Simmons / outlaw programmer wrote: HTTPS has been proven insecure
That's a pretty bold claim. Do you have a link to back that up?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
No, but I'm almost positive you have access to google. I don't recall the specifics.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I've seen a few conspiracy nuts claiming that HTTPS is an NSA / Google plot to destroy the internet, but their claims are just laughable. 
Troy Hunt: Don't Take Security Advice from SEO Experts or Psychics[^]
HTTPS Anti-Vaxxers; dispelling common arguments against securing the web[^]
Beyond that, as Eddy said, there were a couple of downgrade attacks which would make your request slightly less secure - but still more secure than not using HTTPS in the first place. Those have been fixed now, but I suppose there could be others which haven't been discovered yet.
But as Griff said, encrypting things in Javascript means the encryption key has to be public, so it doesn't really add any benefit.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: encrypting things in Javascript
We're in the C# forum so you'll have to excuse the assumption that we were talking about C#. JavaScript is evil and should be avoid at all costs. I equate it to using Active-X in regards to evility.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
OriginalGriff wrote: If it's a website, …
I was assuming we were talking about a website, where encrypting things on the client would mean using Javascript.
I guess it's true what they say about "assume".
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Trouble is that when you start talking about passwords, and "back end" or client / server architecture, nearly all the time you are talking about a javascript based client (which while execrable is vastly safer than Active-bloody-X was) - and that means public source code, and public encryption. Nasty. 
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
There were some protocol downgrade attacks, but that should not happen on a modern machine.
So, which insecurity?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I don't recall specifically. In the end, there's absolutely nothing wrong with an additional layer of security. I was just tossing the idea out there.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
John Simmons / outlaw programmer wrote: In the end, there's absolutely nothing wrong with an additional layer of security.
There is!
It adds complexity, a point of failure, and hence, a point of attack. Think of it as using two condoms; you think you're safer, while the integrity of both lubbers is not guaranteed.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
You're confusing specific issues with general insecurity. HTTPS over SSL has been prohibited,. TLS should use version 1.2 or later (with no fallback to SSL.)
Heartbleed was a vulnerability in OpenSSLs implementation of TLS heartbeats, which has been fixed.
HTTPS over TLS is secure (for now; all security can, and will, be broken in time.)
|
|
|
|
|
Kevin Marois wrote: The part I'm questioning is that it seems that you have to pass the PLAIN TEXT password to the back end to do the comparing.
What's the right way to do this?
That is the right way.
Hashing on the client would prolly mean that your salt is no longer as secret as you like. It's not done to make the password unreadable during transmission, but to "not" have to store a readable version. Even if the datastore is leaked, hashed passwords are useless.
Imagine me hashing and salting my CodeProject-password on the client, before entering it, and with keeping "my" salt private - would CodeProject in that case not act like my password is a plain text? To CodeProject, the hashed string would seem just like a plain-text password and behave in the same way for all purposes.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
That's precisely why you should never send or load ANYTHING over http if it's got anything to do with passwords (or other sensitive data) - Https encrypts which protects the plain text that you send to the server, and prevents eavesdropping via a man in the middle - hence why everything is loaded via https (if it's not, then you can't guarantee anything)
Troy Hunt has some good explanations on the whys and wherefores
C# has already designed away most of the tedium of C++.
|
|
|
|
|
|
Try creating a .Exe solution and adding your code into it.
This space for rent
|
|
|
|
|
I try installed visual studio 2015 for windows 7 x64bit, when running demo xamarin was reported "No Android NDK found". I go to "Tools> Options> Xamarin> Android Settings" in this tab I see Android NDK Location -> "No Android NDK found" how do i want to install android ndk for visual studio 2015 ? What can I do ?
|
|
|
|
|
|
I have searched google but it's not results are true
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
