The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Anything that is unrelated to elephants is irrelephant Anonymous - The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944 - Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
Meh. You should use multi-factor authentication. Even Shakespeare knew about that!
Eye of newt, and toe of frog,
Wool of bat, and tongue of dog,
Adder's fork, and blind-worm's sting,
Lizard's leg, and owlet's wing,—
For a charm of powerful trouble,
Like a hell-broth boil and bubble.
Double, double toil and trouble;
Fire burn, and caldron bubble.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
If your password is leaked, there is no difference between "qwerty" and 64 random characters.
If it is not leaked, there are just two classes of attacks: Brute force and not brute force - the latter usually employing some sort of dictionary.
For a brute force attack, 64 characters is most certainly an overkill. Even half of that is an overkill. Even half of that, 16 random characters, is so safe against brute force attacks that noone would ever work their way up to it just to sneak in on your email.
A dictionary attack makes an attempt to first try the most likely bit patterns. Like "qwerty" or the name of your dog. If you choose a bit pattern among the likely ones, you are unsafe. If you deliberately choose an unlikely pattern, like CorrectBatteryStapleHorse[^] - well, not that one, but one made according to the xkcd principles - you can both have a password that can be easily remembered and that is almost as safe as random characters.
The problem with these long, non-memorizable random passwords is that they have to be written down. E.g. in vault or safe ... that often can be opened by the use of a hairpin. If an intruder can open your safe by giving "qwerty" as the key, to get direct access to your three dozen of 64-random-characters keys, then your keys are as save as the "querty" password.
I use different keywords in different contexts, all structured in three parts: The first part is for the site or function, always with a twist. E.g. for a mail account, the first part might be 'female'. The second part is my role in that context, again with a twist, like 'awta' for writer of mails. The third part is one of a small set: one is for all IDs relating to money/economy, one is for discussions, and so on. These are keywords deliberately chosen to contain national characters (like æøå) - nowadays, intruders have become somewhat aware of non-English letters, but still the dictionaries are certainly not as rich in other languges; certainly not when you also include transcriptions.
I will never put lots of passwords into a vault where every one of them can be revealed by opening the vault specifying "qwerty" as a hairpin.
You make some great points.
I understand and I agree. My passwords are not in a vault. They are generated every time.
In my app, you have to 1) pick the right "site key" (creates hash) 2) draw the correct pattern (salts the hash) and the subsequently generated (not stored) hash is used as your password.
So my passwords are not stored anywhere, they are generated from the key and the salt (drawn pattern). Mostly I think the idea is interesting, but as you said if passwords are leaked then no password method is secure. Some are just more secure than others.
If you make the password "too long" (many possibilities but eg. longer than the hash field), you will cause collisions in hash output and a brute force attack might discover "abc" also generates the correct hash. This depends on a number of things, including how the hash function deals with "long" passwords. The algorithm is not likely available to you, the user.
I've read somewhere that a password rule to reset your password only makes sense if it doesn't give potential hackers enough time to brute-force into an account and make use of it before it expires. That may be no more than a few days, or just hours. A week is probably too much (unless you require length 20+ passwords written in Kanji) and a month is entirely pointless.
Therefore the best way to use this rule, is reset the password with every use. Oh, wait, that's what you did!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Therefore the best way to use this rule, is reset the password with every use.
There was a site I logged into once a year and in the past I could never remember the password so every year I would reset it. Then when I would make a new password I would just roll my hands across the keyboard so even I didn't know the password. The most secure password of all is one that you don't even know.
Basically at that point your email is your way into the site. But better make sure you email password is really strong.
I have a financial site that updates my figures annually and sends an email once a year to tell you that the figures have been updated. Its password expiration period is one month, so every time I use it I have to get a new password and it won't let me change then change back as it keeps a password history. If you are going to use expiring password, make the frequency commensurate with the frequency of use. Why not have something like 'You have used this password n times, change it in the next x logins' so it is usage based rather than arbitrary date based.
...why is MS rolling out a "Servicing Stack Update" for 7 / Server 2008 R2, since this is their last update...?
I mean, typically these have been released so, moving forward, updates will install faster, more efficiently, the payload's gonna be smaller, etc. But if there's nothing else coming down the pike for those operating systems...what's the benefit?
I'm willing to bet it's got its own requirements, so you wouldn't be able to do a clean install of (say) Win7, then install that update, and then retroactively install the previous ones...
But what do I know...this makes as much sense as releasing this new Chromium-based Edge browser for 7 the same week 7 itself goes out of support...