|
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.
Real programmers use butterflies
|
|
|
|
|
|
Ah, the _mbsstr woes. I remember them well pretty poorly, actually. I've got to get more memory fitted.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: I've got to get more memory fitted.
Installation is the easy part. Loading it with (useful) data is more of a problem.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
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 :
paraphrase: "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).
Oy!
|
|
|
|
|
The SFBs at newegg.com just did this to me.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
|
It's just a scheme to get you to visit their site more frequently.
Any site that does that deserves to be removed from my bookmark list. And Google's index. See how quickly they change their minds...
|
|
|
|
|
That makes no sense
This surprises you?
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
theoldfool wrote: This surprises you?
|
|
|
|
|
My web apps must be signed into with blood.
I take online security seriously.
Real programmers use butterflies
|
|
|
|
|
Being a witch has gotten boring, so you're reinventing yourself as a vampire?
|
|
|
|
|
honey the codewitch wrote: My web apps must be signed into with blood.
Your own or somebody elses? 
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
|
|
|
|
|
honey the codewitch wrote: My web apps must be signed into with blood.
Meh. You should use multi-factor authentication. Even Shakespeare knew about that!
Quote: 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.
|
|
|
|
|
Member 7989122 wrote: I will never put lots of passwords into a vault
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'm retired. There's a nap for that...
- Harvey
|
|
|
|
|
Oh No! 
Obviously, reading your message, it struck me now that password policy should be upgraded with AI to detect and refuse computer generated password now! 
This formerly smart password policy[^] is definitely too lenient now!
|
|
|
|
|
Super Lloyd wrote: should be upgraded with AI
absolutely! Without AI there is no way insure security. 
|
|
|
|
|
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)
|
|
|
|
|
Stefan_Lang wrote: 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.
|
|
|
|
|
|
It "application" GIF in the comments was the best bit...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
