61–70 of 111 posts
Earlier quoted context omitted.
Mandatory https isn't a law, either. Good thing or HN would be in violation of it.
So?
I always use site specific, but also site derived passwords. I think it's time to reevaluate that practice. I remember seeing that three of the top password fragments for LinkedIn were link, job, and work. My password was all three... oops.
Earlier quoted context omitted.
So?
To be clearer, my point was that HN not using HTTPS doesn't seem like a reason not to require sites to use HTTPS, let alone introducing any security regulations at all.
where x is the length of the password you want.
Earlier quoted context omitted.
It will get to the point that we need biometric scanners or implanted RFID chips with private keys to do authentication, since brute forcing even unrememberable passwords will be trivial eventually.
Why? There are plenty of ways to make brute force hard or damn near impossible, it's just a little harder to implement. It has been discussed a lot of times here at HN and other places. Also, do you really think that storing private keys on RFID would be a wise choice? I would put that in the "stupid as fuck"-category, just above storing your keys on a USB-stick, as they are both easy to copy and duplicate, and with…
Slow hash function certainly help, but I think we also need something that goes beyond straightforward cryptography to address authentication issues. Something that redefines the rules of the game to be more human-friendly and less computer-friendly.
But then again, I never even heard the question being phrase this way: what do we want from "program-less" authentication and what we can use to achieve it.
Earlier quoted context omitted.
You might want to look at a browser extension like PwdHash [1]. It uses a client-side script to generate a cryptographic hash from your common password and the domain name. I've been using it for about four years now and have been generally very happy. It means that if my password ever gets leaked the attackers are not only unlikely to find my password of "ngjO3uBJrvt", but if they get it they do not have any informa…
I don't use that because of (unfounded) concerns that I will someday need to enter my password into some device where it's not available, or the domain will change, or some other scenario where bad things will happen because I do not actually know the password I told the site.
Earlier quoted context omitted.
Well, calculating the "true" strength is difficult to do, because even though sophisticated tools are available to aid the process, the attackers are still human, and can input their own guesses that may or may not be more accurate. If the attacker knows (or can closely guess) the password rules used to generate your password, he or she has a better chance of getting a hit. Let's look at a password like "My first car…
Beautifully written. Also worth noting is that sites exist that only use lower(trunc(password, 8), so your first 8 characters should be sufficiently random. For the grandparent, that leaves "my first", which is especially weak in a dictionary attack.
I guess if someone stole their database it would be impossible to know your real password, but still...
Or am I missing something here?
Here's a useful one-liner to create a strong password in Linux: cat /usr/share/dict/words|egrep -v "é|'s$|[Åå]|[Øø]"|shuf --random-source=/dev/random -n4 This uses the dictionary /usr/share/dict/words and skips all the words containing characters like é, å, ø and all those ending in 's . The resulting word list has 72,940 words in it. Then it chooses 4 random words from this dictionary and prints them to the screen.…
Here's a useful one-liner to create a strong password in Linux: cat /usr/share/dict/words|egrep -v "é|'s$|[Åå]|[Øø]"|shuf --random-source=/dev/random -n4 This uses the dictionary /usr/share/dict/words and skips all the words containing characters like é, å, ø and all those ending in 's . The resulting word list has 72,940 words in it. Then it chooses 4 random words from this dictionary and prints them to the screen.…
function mkpw () {
if (( $# == 0 )) then
head /dev/urandom | uuencode -m - | sed -n 2p | cut -c1-${1:-12}
else
head /dev/urandom | uuencode -m - | sed -n 2p | cut -c1-${1:-$1}
fi
}
Earlier quoted context omitted.
Well, calculating the "true" strength is difficult to do, because even though sophisticated tools are available to aid the process, the attackers are still human, and can input their own guesses that may or may not be more accurate. If the attacker knows (or can closely guess) the password rules used to generate your password, he or she has a better chance of getting a hit. Let's look at a password like "My first car…
One improvement: for most people, the risk is not that someone tries to crack your password, it is that someone uses rainbow tables to crack many passwords, one of which may be yours. Rainbow tables have a degree of freedom: the function that maps hashes back to passwords. You should try and pick a password that that function will never generate. To get that, do something unique. Good options, I think, are including…