I wonder if Jeff and his team know about Dropbox's password strength estimator: https://github.com/dropbox/zxcvbn
Hacker, Hack Thyself
11–20 of 114 posts
Re: Hacker, Hack Thyself
#12I'm comfortable using passwords But those are bad comparisons. A key and lock is an asynchronous single use authentication+authorization mechanism. Passwords are just the authentication part, so trying to replace these just requires we have a secure way to authenticate ourselves.
We have the benefit that we are using digital systems, so our authentication can be digital, too. We can also rely on multiple factors to improve how authentic this process is. Biometrics, digital files, access to other accounts and networks, offline code generators, and personal information all provide lots of authentication data and multiply the effort needed to defeat the system. By combining all these factors, we can create a new digital key that is far more difficult to defeat than old methods by themselves, and ultimately is more flexible because it can be made up of any of these things.
The problem mainly seems to be that we live in a world of different locks, and most locks don't accept this particular kind of digital key. We've hacked around this problem and made some attempts at more compatible solutions, but they really fall short of their true potential.
In the future, you should simply be able to use any system and know that it will authenticate you in a way that can't be copied or cracked. Today that just isn't the case. So for now, maybe we should move the goal posts. We can keep making our keys more unwieldy, but we can also get more guard dogs.
The guard dogs need to exist not only to protect the locks, but the keys, too. If you go to unlock a door, a thief can knock you out and steal your key. Each aspect of our digital access needs guard dogs. We can no longer accept insecure communication methods, nor insecure computing platforms, to exchange our authentication. I think the real challenge going forward is rethinking how we process data altogether.
Re: Hacker, Hack Thyself
#13I saw a very interesting talk last year from someone who, as part of a company's security team, had set up a system that continually attacked the hashes of every employee's Active Directory passwords. If one was cracked, the employee would receive an automated email with a note containing the last few characters of their password and a suggestion to change it. I recall they also spoke on some security aspects of the…
I used to work at a University in the UK. One of my responsibilities was the email system. We constantly suffered targeted phishing attacks where the sender pretended to be from the IT department and required the recipient to respond with their password, for various made up reasons. Our spam filters captured most of these on the way in, but some still got through. And people replied. People replied all the time. Stud…
That's seriously cool!
I was reading about something similar for CI servers to compare the stdout/err to the values of all initialized secrets and if any strings match, filter them out. It's a simple way to block "echo $SECRET_STUFF" from publishing to a public log. It doesn't catch everything as it'd still be possible to curl out to transmit information, but it does work quite well for the more common case of "*Let me dump all environment cars to debug why this isn't working...".
Re: Hacker, Hack Thyself
#14I saw a very interesting talk last year from someone who, as part of a company's security team, had set up a system that continually attacked the hashes of every employee's Active Directory passwords. If one was cracked, the employee would receive an automated email with a note containing the last few characters of their password and a suggestion to change it. I recall they also spoke on some security aspects of the…
Where you use this is important, too. Accounts that can provide remote access or admin rights should be scrutinized heavily, whereas an office temp with an email address (and no access from the outside world) isn't much of a threat.
Re: Hacker, Hack Thyself
#15Suuuper nitpicky, but in the paragraph directly below Dark Helmet, Jeff calls his Graphics Card a 1080 GTX Ti. The GTX goes in front of 1080, since GTX is the general product line.
Re: Hacker, Hack Thyself
#16What this shows is that even with best practices passwords are a fairly weak security control. We need a standardised second factor id.
The FCC or corresponding body elsewhere should mandate that phone networks and phones support a secure messenging protocol which could guarantee that a message could be sent to a phone number and only be received by that device.
Password-only authentication is like locks on luggage, even with best practices.
Re: Hacker, Hack Thyself
#17Is my math failing me or wouldn't 8 digits result in 10^8 possibilities rather than 8^10?
Re: Hacker, Hack Thyself
#18Encrypting the hashes in the database would make it safer. That way the password hashes can't be attacked in this way unless they can decrypt them first.
Re: Hacker, Hack Thyself
#19Suuuper nitpicky, but in the paragraph directly below Dark Helmet, Jeff calls his Graphics Card a 1080 GTX Ti. The GTX goes in front of 1080, since GTX is the general product line.
You are correct. It is a mistake. It's also confusing naming, because not too long ago, nVidia named their cards with GT and GTX as a suffix, such as the GeForce 8800/9800 GT and GTX.
Re: Hacker, Hack Thyself
#20I built my latest application using Amazon Cognito for user management. My application and database don't ever know anything about the passwords. Amazon's problem.
> Amazon's problem.
Delegate to someone else™ isn't always the answer to your security problems. It only adds more complexity, no more or no less security.