|
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!
|
|
|
|
|
...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...
|
|
|
|
|
It's main content is probably the already-infamous nag screen.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
My first through third thoughts as well.
Maybe also that NSA fix, but I doubt it.
TTFN - Kent
|
|
|
|
|
Kent Sharkey wrote: Maybe also that NSA fix, but I doubt it.
Doubt no more. CVE-2020-0601 doesn't affect 7 or 2008 R2. Besides, a fix for that wouldn't be in a servicing stack update.
|
|
|
|
|
Mark_Wallace wrote: It's main content is probably the already-infamous nag screen.
You're thinking of KB4493132, which I've banned from my WSUS server. Haven't seen a single nag screen on any of my Win7 or 2008 R2 VMs.
Microsoft does document these things. Back when everyone was complaining about the never-ending stream of Win10 nag screens on Win7, I also had those blocked and never saw a single instance.
|
|
|
|
|
How dare you ruin a perfectly good snark with something like facts!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Sorry. One of my habits. 
|
|
|
|
|
Maybe they wish to brick your Win7 to force you to move on...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
I'll be running a machine with multiple VMs so I want cores to spare.
8 cores is more than enough. 4 is about minimum.
I'll need the various VM bells and whistles like HyperV support and VTx whatever of course.
I don't really game per se, though for this kind of money I wouldn't mind being able to game with the machine if i wanted to. i play the fallout franchise at least.
I'm considering either an i7-9700(k?) or an i9-9900 or whatever. I think the i9 will come down this year and be in budget. *knock on wood*
anyone use either of these CPUs heavily and can tell me, particularly when using VMs if they're happy with it, or if they would have gone better in retrospect?
Or any alternatives to suggest? (I strongly prefer Intel to AMD cpus)
I'm curious mostly, leaning toward the i9 for future proofing, assuming it's not still bleeding edge by the time i buy and i can afford it.
Real programmers use butterflies
|
|
|
|
|
How many simultaneous VMs will you be running, and what OS will be in them?
Since I run Linux as my host, I can dedicate most of the system resources to the VMs (when they're running)
You need a cpu that will support at least 64gb of ram, and I would recommend no fewer than six cores. My personal pref for cpu's is AMD.
For gaming, it's more about the video card than the rest of the box, and I'm assuming you won't be running any VMs while you're running the game. For the video card, no less than 4gb of DDR5 RAM, and 6-8 gb would give you the best experience. I personally prefer nVidia video cards.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
