james
Posts: 2,205
Likes: 955
|
Post by james on Nov 22, 2016 10:51:51 GMT
In what form does Collateral store the password-related and secret-related information that is used to log in?
Insecure methods include things like:
1. plain text
2. hashed
3. cryptographic hash
4. salted cryptographic hash
Secure methods include things like:
A. storing say two thirds of a salted cryptographic hash so that the potentially matching passwords are too numerous to allow identification of the actual one used.
B. for secrets where letters are asked for, storing only a set range of permutations in a partial salted cryptographic hash form.
The difference? The secure methods are still secure if everything on the site is stolen, the insecure ones aren't and allow the information to be tried as logins to a lot of other sites to magnify the damage.
Background on this is that I play a role in approving the security solutions of one of the most attacked platforms on the internet with lots of cases of theft of database contents happening. The security designs of the platform are arranged to be reasonably secure even if its login database information is stolen. And I look for similarly secure designs at places I use, since these attacks are just routine these days and modern designs have to be robust against them.
|
|
greatmarko
Member of DD Central
Posts: 343 
Likes: 373
|
Post by greatmarko on Nov 22, 2016 11:00:15 GMT
I'm also interested in this! I've had my eye on Collateral for some time now, but I just can't get comfortable with their approach to security to risk trusting them with my personal/financial details. Their website is pretty poor (based on Wordpress by the looks of things), with login forms accessible over insecure http, old versions of the site still accessible online, etc, and a number of posts here raising a plethora of security concerns (i.e. this thread). I'm keen to invest, but it just doesn't sit well with me - for a business of this nature, they don't seem to have the appropriate security expertise/ability to respond to security incidents (i.e. if their "IT security specialist" is on holiday, you'll have to wait for him to get back before any security issues/events are looked at!) So I'd like to echo james 's question, and also ask collateral / Collateral Rep whether their website and database have been independently security audited/PenTested by a reputable security firm? |
|
james
Posts: 2,205
Likes: 955
|
Post by james on Nov 22, 2016 14:16:58 GMT
Thanks. Yes, even having the technical ability to provide the plain text password indicates that it is available somewhere. In a secure design it has to be impossible for that to be technically doable even with access to the stored version and knowledge of exactly how the site works. Verifying that a password has been supplied correctly just doesn't need the storage of the whole hashed password, let alone the plaintext password. While the sending part seems fixed there's still the risk that the storage is insecure and that a compromise of their back end would compromise the passwords.
|
|
|
|
Post by Collateral Rep on Nov 22, 2016 15:10:46 GMT
Hi james, We don't like discussing our security on a public forum. We are fully secure and would be more than happy to answer any queries you may have by confidential email. Please feel free to send your questions to info@collateraluk.com and we will pass them onto the developers to give their answers etc. Many thanks, Gordon |
|
greatmarko
Member of DD Central
Posts: 343
Likes: 373
|
Post by greatmarko on Nov 22, 2016 15:15:57 GMT
Hi james , We don't like discussing our security on a public forum. We are fully secure and would be more than happy to answer any queries you may have by confidential email. Please feel free to send your questions to info@collateraluk.com and we will pass them onto the developers to give their answers etc. Many thanks, Gordon Gordon, with respect, if you're storing passwords correctly there should be no issue publicly disclosing how they're being encrypted & stored! The inability to provide straight answers suggests that you either don't know how they're being encrypted/stored (which is worrying!) ....or that they aren't being securely encrypted/stored at all! (which is also worrying!) Also, if you allow login/registration over an insecure http connection, you're by no means "fully secure"! One of the most dangerous things a company can do is to adopt a dismissive attitude when it comes to their security!
|
|
|
|
Post by Collateral Rep on Nov 22, 2016 15:23:59 GMT
greatmarko , Passwords are hashed to a level that is recommended for situations where security is vital. Many thanks, Gordon
|
|
|
|
Post by richardthe4th on Nov 22, 2016 15:28:37 GMT
I don't know a lot about internet security (as this post may demonstrate) but surely if the site is hacked then, since I don't use the same password etc, any other sites that I use will remain unaffected?
To withdraw money from my account would involved contacting Collateral and supplying ID and changing the attached bank account so there is an additional level of security before anyone can get at my cash....
Or am i missing something?
|
|
greatmarko
Member of DD Central
Posts: 343
Likes: 373
|
Post by greatmarko on Nov 22, 2016 15:29:24 GMT
greatmarko , Passwords are hashed to a level that is recommended for situations where security is vital. Many thanks, Gordon I'm afraid that's far too vague to be of any use/comfort! What is your understanding of a "hashed to a level that is recommended for situations where security is vital"? For instance, what hashing method is being used (SHA1, MD5, bcrypt etc)? ...are the hashes salted, randomly salted, or unsalted?
|
|
james
Posts: 2,205
Likes: 955
|
Post by james on Nov 22, 2016 16:05:00 GMT
Passwords are hashed to a level that is recommended for situations where security is vital. And if the whole hash is stored, the site has an insecure design because knowledge of hash and salt permits reasonably ready identification of the password, in site hacked cases. I'll probably do some email followup though I agree that disclosure in public of this should not be a problem because if the design is secure it makes no difference to the security of the site in the posited everything on the site is stolen situation. To illustrate, plug the plain text Collateral Rep into an online SHA256 calculator (left box). Out pops the hash that looks secure cd65837cc1b7c7f1f776a71893c0d07d20a483d12ef1fd467ea248e29e460877 until you notice that the decoded value is also provided and available to anyone with such a tool. A salt adds a bit more complexity to the work. If instead only cd65837cc1b7c7f1f776a71893c0d07d20a is stored (in binary form of course, I didn't bother to pick a suitable number of bits for that) there's a good deal greater challenge in getting to the plain text of the password because there are so many possible passwords which produce that output.
|
|
locutus
Member of DD Central
Posts: 1,059
Likes: 1,622
|
Post by locutus on Nov 22, 2016 16:26:30 GMT
Passwords are hashed to a level that is recommended for situations where security is vital. And if the whole hash is stored, the site has an insecure design because knowledge of hash and salt permits reasonably ready identification of the password, in site hacked cases. I thought a hash was one way only. i.e. even with the hash and salt, you can't recreate the password.
|
|
greatmarko
Member of DD Central
Posts: 343
Likes: 373
|
Post by greatmarko on Nov 22, 2016 16:56:14 GMT
And if the whole hash is stored, the site has an insecure design because knowledge of hash and salt permits reasonably ready identification of the password, in site hacked cases. I thought a hash was one way only. i.e. even with the hash and salt, you can't recreate the password. It very much depends on the hashing algorithm and the type of salt - some passwords can be easily cracked if using a weak hashing algorithm with no salt/or a salt of fixed length, etc - this is why it's important to know the hashing algorithm being used by collateral.
|
|
shimself
Member of DD Central
Posts: 2,561
Likes: 1,170
|
Post by shimself on Nov 22, 2016 17:38:10 GMT
Hi james , We don't like discussing our security on a public forum. We are fully secure and would be more than happy to answer any queries you may have by confidential email. Please feel free to send your questions to info@collateraluk.com and we will pass them onto the developers to give their answers etc. Many thanks, Gordon Go on James, collateral rep here is out of his depth, talk to the devs and report.
|
|
|
|
Post by Collateral Rep on Nov 22, 2016 18:53:31 GMT
Hi,
From the developers.
Our passwords are hashed and salted, and each salt is unique each time - to 64 characters. So something like md5hashing.net would not be able to de encrypt. Also to address the other point that was made, no screen is accessible without https.
Hope this explains the password security for you a little better.
Many thanks,
Gordon
|
|
james
Posts: 2,205
Likes: 955
|
Post by james on Nov 22, 2016 19:20:08 GMT
And if the whole hash is stored, the site has an insecure design because knowledge of hash and salt permits reasonably ready identification of the password, in site hacked cases. I thought a hash was one way only. i.e. even with the hash and salt, you can't recreate the password. The wikipedia article on salt explains a fair bit about this quite well. A site that uses a salt approach might do something like combining an account name and a site-wide value and perhaps the email address and doing some manipulation to get a salt value that is mixed in with the password. That's then hashed with the idea that just reversing the hashing doesn't get you directly to the password. An issue with this is that in full site data theft situations all of the salting information is stolen as well as the hashed passwords. And that's where storing only part of the hash comes in: even if you have everything you still can't get back to the password because there are too many possible passwords that match what you've stored. And you don't need the whole hash to have very high confidence that the real password has been supplied. So essentially there's nothing to gain by storing the whole hash and it just makes the damage in a successful attack worse if it's done. Any place that can tell you your password or where the developers can do it with full knowledge of how the place works is unnecessarily vulnerable and it's pretty trivial to reduce the vulnerability just by throwing away part of the hash or replacing part with zeros if there's some reason not to want to do that.
|
|
greatmarko
Member of DD Central
Posts: 343
Likes: 373
|
Post by greatmarko on Nov 22, 2016 21:51:06 GMT
Hi, From the developers. Our passwords are hashed and salted, and each salt is unique each time - to 64 characters. So something like md5hashing.net would not be able to de encrypt. Also to address the other point that was made, no screen is accessible without https. Hope this explains the password security for you a little better. Many thanks, Gordon Appreciate your response and your attention to this matter, Gordon! - and I'm pleased to note that your developer has now indeed resolved the insecure http issues! (He may also still want to look at removing obsolete versions of your site from your server though too!) I'm also pleased to learn that random salts are indeed being used - however, I really do hope you're not using MD5 hashing?! (even with salts, MD5 is widely considered to be inadequate for password storage by today's security standards, not least of all because it's a "fast hash function" meaning that computers can calculate millions of MD5 hashes per second). In the unfortunate event that your database was every to be compromised, if passwords are stored in MD5 hashes - even if they're salted - it would not be beyond the realms of possibility for some/many of those passwords to be cracked.
|
|
