Slashdot Mirror

>> So basically, Google is giving you access to their hash, salt, and saying "Enjoy unlimited cracking attempts...

Not exactly. The 37-bit version is just less than 25% of the full 160-bit SHA-1 so, as the source mentions (https://raw.githubusercontent.com/google/password-alert/master/SECURITY.md) the intent is to keep enough of the password to tell when the same password has been tried twice, but not enough of the hash to allow someone to authoritatively crack it. (I hope - haven't seen the proof of 37-is-the-right-number yet.)

This isn't the first time someone's used hashes with high collision rates to see if the same passwords are being tried without actually storing enough of a hash to flag the password. See this article for a different example (trying to tell badly configured clients from brute forcing attempts): http://www.filetransferconsult...

OK - here's a niche industry page listing about forty open source, commercial and cloud solutions that all have secured by SSL and their responsed to heartbleed:
http://www.filetransferconsult...

Of these...maybe a third had OpenSSL...most of the rest used a Java stack, and many of the rest were on IIS or using MS crypto. Within my own company (about 1500 people and 20 web apps on a mix of platforms), heartbleed affected exactly 3 sites.

If you looked around other industries and saw >50% affected rates maybe I'd believe "monoculture"...but if you're talking the entire web dev world, OpenSSL is just one of the top options.

As a "pen tester"... Since FTP servers aren't often monitored as closely as higher-profile web applications, but are still often tied into a company's AD or other common credential store, they're often a great resource to use if you want to harvest some high-value credentials before you go on site. (I like to use this:
http://www.filetransferconsult... for that.)

You can use this free scanner to test your FTP or SFTP access.
http://www.filetransferconsulting.com/low-and-slow-ftp-scanner/

Set this utility up with about four garbage usernames, then your actual admin credentials in the username list, and put four junk passwords before your admin password in the password list. Then run the utility with one-second intervals. If your FTP server (or SFTP service) is set up well, your IP (and possibly your username) should be locked out before the utility gets to your legit credentials on its 25th try. (In other words, if the utility can sign on as you, your FTP or SFTP service could use some additional security.)

For FTP over IPv6, read this:
http://www.filetransferconsulting.com/File_Transfer_IPv6_Readiness.pdf
(It's a report on interoperability performed for LAST year's IPv6 day.)

Here's a page that's tracking this for file transfer applications that includes a nice discussion of general purpose web servers and browsers and their current "support of TLS v1.1" status at the end: http://www.filetransferconsulting.com/file-transferbeast-tls-vulnerability/

I think there's light at the end of the IPv6 tunnel. Now that the world knows that the IPv4 game is up (not withstanding events like June 8's "World IPv6 Day") the pressure to convert to IPv6 will come fast and furious. Hell, someone's even figured out how to get FTP running on IPv6, and that's a 40-year old protocol!