111–120 of 216 posts
As an old I strongly object to the corruption of the terms "hacking" and "hacker" in the diatribe following this heading. I'm a fan of hacker culture, in the old sense, and encourage our developers to adopt a hacker mindset when approaching the problems they're trying to solve. Hacking is cool.
Earlier quoted context omitted.
> The phrase "more secure" doesn't mean anything Fair point. I'll elaborate: The linux (UNIX) security model is designed to protect users from other (potentially malicious) users on the same computer. The system as a whole is designed such that a malicious (or incompetent) user can't make the system as a whole stop working. The system is more important than any particular users' data. Software is assumed to be correc…
> Its much more likely that me or my family suffers from a keylogger or ransomware attack than we suffer as a result of government intrusion into our digital lives. Are you sure? How would you know? We can't know how many people the government blackmails with data taken from their iphones, because it's illegal to publish information about them doing so, whereas ransomware attacks are widely publicised.
I would counter the “government blackmailing people” by questioning the risk this poses to me as an individual. As much as we’d like to imagine it, and as much as it can often times feel like it, we don’t live in a Kafkaesque society, by and large, as the significant majority of us are of zero interest and have little of anything worth blackmailing.
> 6) Action is Better Than Inaction
I’m a fan of the
> don’t just do something, stand there!
As a sysadmin, I took this approach as well. On the local machine, the server(s) would log normally. But, when I set-up centralized logging, I set-up a list of log entries that wouldn't normally interest me day-to-day. The server would only send to a central logging server things that weren't on this list. What was left were usually problems that I would need to pay attention to and they got fixed faster.
The rest of the uninteresting log entries would just be audited from time to time.
On the matter of security, every user that logs in on a daily basis gets logged with their IP address. Anytime that a user logged in with a different IP - it would get logged to the central log server and I would be notified. Most of the time, it was harmless.. but there were enough times I would find a compromised account in a sea of normal day-to-day login activity.
When your logs are full of normal things in it, it's easy to miss important details.
Earlier quoted context omitted.
I don't think the author intended to say that you can prevent all problems, I think they meant you can't just shrug and say "we can't help but get hacked". You can stop all problems from becoming critical, which is what airlines attempt to do. They talk earlier about defense in depth, so it's obvious that they're not oblivious to the need for redundant safety measures: > "We don't need a firewall, we have good host s…
Maybe I'm being too harsh, but my interpretation of that point is that they expect we'll eventually become perfect, which isn't going to happen in the software world as it hasn't happened in the airline world, even though the airline world has more incentives to be perfect in the form of more penalties when it isn't.
> #4) Hacking is Cool As an old I strongly object to the corruption of the terms "hacking" and "hacker" in the diatribe following this heading. I'm a fan of hacker culture, in the old sense, and encourage our developers to adopt a hacker mindset when approaching the problems they're trying to solve. Hacking is cool.
> but the second version used what I termed "Artificial Ignorance" - a process whereby you throw away the log entries you know aren't interesting. If there's anything left after you've thrown away the stuff you know isn't interesting, then the leftovers must be interesting. This approach worked amazingly well, and detected a number of very interesting operational conditions and errors that it simply never would have…
At this point I am elbow deep in bayesien email code trying to work out the nuts and bolts of the operation. One important trick is that you need a location aware hash to feed into your statistics engine. A better hash would utilize the structure of log lines, but categorizing logs is big messy yak shaving sort of work. Perhaps a worse more generic hash would be good enough.
Not convinced these are the dumbest (none of them is quite as dumb as requiring special characters in passwords, for example, and I'm not sure the fourth is dumb at all), or that they're six ideas. The first two are the same, and the third one is a special case of the same thing.
I've been looking for a new bank in the last week. Actual password practices I have encountered in 2023: * ME Bank: Password must be between 6 and 20 chars long and consist entirely of numbers * Westpac: Password must be exactly six (6) characters long, letters and numbers only
Not convinced these are the dumbest (none of them is quite as dumb as requiring special characters in passwords, for example, and I'm not sure the fourth is dumb at all), or that they're six ideas. The first two are the same, and the third one is a special case of the same thing.
I've been looking for a new bank in the last week. Actual password practices I have encountered in 2023: * ME Bank: Password must be between 6 and 20 chars long and consist entirely of numbers * Westpac: Password must be exactly six (6) characters long, letters and numbers only
Various SAP-based systems: special character in password is required... but not THIS special character, different one.