September/October 2018 issue of acmqueue The September/October issue of acmqueue is out now

Subscribers and ACM Professional members login here



The Bike Shed

Security

 

Error 526 Ray ID: 47c8b2a0b879c5fa • 2018-11-20 06:00:42 UTC

Invalid SSL certificate

You

Browser

Working
Newark

Cloudflare

Working
deliverybot.acm.org

Host

Error

What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.

acmqueue

Originally published in Queue vol. 10, no. 6
see this item in the ACM Digital Library


Tweet


Related:

Rich Bennett, Craig Callahan, Stacy Jones, Matt Levine, Merrill Miller, Andy Ozment - How to Live in a Post-Meltdown and -Spectre World
Learn from the past to prepare for the next battle.


Arvind Narayanan, Jeremy Clark - Bitcoin's Academic Pedigree
The concept of cryptocurrencies is built from forgotten ideas in research literature.


Geetanjali Sampemane - Internal Access Controls
Trust, but Verify


Thomas Wadlow - Who Must You Trust?
You must have some trust if you want to get anything done.



Comments

(newest first)

Displaying 10 most recent comments. Read the full list here

bendra | Tue, 17 Jul 2012 22:04:51 UTC

Hello,

Interesting article and comments! One thing this has me wondering is: if GPUs are so darn good at hashing, is there anyone who is using GPU-based hashing on the server to log users in? It would take quite a load off the server, particularly if you are using a slow adaptive hash no?


Michael | Thu, 14 Jun 2012 09:45:17 UTC

@Cory House: Eh, the salt and algorithm should not need to be secret. The password should. If the channel is safe enough to transmit a plain text password, it is also secure enough to transmit a hash of that password.

If the channel is being sniffed, it is also better that a hash is discovered, which is only valid for a single website, due to the salt, while a password is likely valid for many websites.


Cory House | Wed, 13 Jun 2012 15:37:24 UTC

@Michael - Login should use https to assure sending the plain text password is safe. The password must be hashed on the server to avoid exposing the hashing algorithm and salt in client-side code.


Michael | Tue, 12 Jun 2012 15:32:57 UTC

@PB | Fri, 08 Jun 2012 09:08:17 UTC "Could it be changed even sooner than that by generating salted hashes of the stored hashes? Then when someone logs in you can simply try both?"

Shouldn't the hash and not the password be transmitted over the internet? This also distributes the computation issue to all user computers instead of a single webserver.


Poul-Henning Kamp | Tue, 12 Jun 2012 10:27:54 UTC

@Anon:

Please see the SHARCS conference presentation linked to in the article for stats.


Anon | Tue, 12 Jun 2012 00:05:48 UTC

"Recent research has managed to get a GPU processor very close to 1,000,000 md5crypt operations per second ... and that means that any 8-character password can be bruteforced in approximately two days."

Your calculation assumes an 8-character lowercase a-z password, not "any 8-character password". If you assume that your password can be made from the 52 upper and lower case letters, the 10 digits, the 32 keyboard symbols, and spaces, your time goes from 2 days to 200 years.


shackrock | Sun, 10 Jun 2012 15:36:59 UTC

I always have used this webpage as a guide: http://elbertf.com/2010/01/store-passwords-safely-with-php-and-mysql/ - which seems to cover all of your statements from the article, agreed?


Nate | Sun, 10 Jun 2012 04:37:30 UTC

If you had an existing salted, SHA1 password database, couldn't you convert everyone instantly to a new combined algorithm that first computes the salted SHA1 and then passes it through bcrypt using the same or (even better) a second salt. Then, assuming your system is un-compromised, you'd have a very secure password hash without requiring users to log in or change passwords.

Any opinions on whether that would work? Seems like it would in my opinion. I'd rather not wait for users to log in/change passwords to ensure the password db could not be compromised by brute force. The one I'm dealing with is already salted, but uses SHA1 and I'd like to take it to the highest standard.


Ben | Sat, 09 Jun 2012 12:37:52 UTC

"The 6.5 million hashed passwords in all likelihood represent far more users than that, because everybody who chose "qwer5678" as a password shares a single entry in that file."

So how are the password statistics concerning this leak even possible when no other information but those pw hashes are available?


Mike | Sat, 09 Jun 2012 07:38:16 UTC

@Matt:

In your calculation where you came up with 600,000 years, you used the ops/sec of md5crypt (1,000,000/sec)

LinkedIn was not using md5crypt, but SHA1, which can be brute forced much faster.

You are also assuming a single computer. Presumably the attackers would have a botnet with tens of thousands of computers or more.


Displaying 10 most recent comments. Read the full list here
Leave this field empty

Post a Comment:







© 2018 ACM, Inc. All Rights Reserved.