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.
I think it would actually be easier to support unicode in .NET if .NET didn't purport to support unicode.
I'm making a lexer generator that supports unicode and the char datatype is absolutely useless for it.
I have to read unicode data directly as raw bytes just so i can process it properly because the BCL will not give me the information i need about the characters. So much of the unicode information is hidden they may as well have not supported it at all.
Password policies are often just set by the whim of some web dev.
I just attempted to sign into Barnes & Noble site so I could buy something.
It's been about 6 months since I signed in so in their infinite wisdom they told me :
"Your password has expired since you haven't signed in lately."
So, I had to get an email link, and change my password. I tried to use the same one I had previously used and they knew it was the same one. I guess they just checked the hash...hope they don't store the pwd in cleartext.
Think about how dumb this really is. If a hacker had the password then she would've signed in and kept it fresh. But since the password hadn't been used they think it has been compromised in some way. That makes no sense.
Plus, now they used more time of a valid customer / user and I had to update my password generator to use the new key (password manager).
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.