Everything old is new again :) We used to call this the Scunthorpe problem. https://en.m.wikipedia.org/wiki/Scunthorpe_problem
Writing "/etc/hosts" breaks the Substack editor
201–210 of 370 posts
Re: Writing "/etc/hosts" breaks the Substack editor
#202Earlier quoted context omitted.
I found an example! https://retail.direct.zurich.ch/resources/definition/product... Questionnaire Zurich Cyber Insurance Question 4.2: "Do you have a technically enforced password policy that ensures use of strong passwords and that passwords are changed at least quarterly?" Since this is an insurance questionnaire, presumably your answers to that question affect the rates you get charged? (Found that with the help o…
Directly following is question 4.3: "Are users always prevented from installing programs on end-user devices?" Totally bonkers stuff.
You install software via ticket requests to IT, and devs might have admin rights, but not root, and only temporary.
This is nothing new though, back in the timesharing days, where we would connect to the development server, we only got as much rights as required for the ongoing development workflows.
Hence why PCs felt so liberating.
Re: Writing "/etc/hosts" breaks the Substack editor
#203Earlier quoted context omitted.
Directly following is question 4.3: "Are users always prevented from installing programs on end-user devices?" Totally bonkers stuff.
A trend for corporate workstations is moving closer to a phone with a locked-down app store, with all programs from a company software repo. Eliminating everything but a business's industry specific apps, MS Office, and some well-known productivity tools slashes support calls (no customization!) and frustrates cyberattacks to some degree when you can't deploy custom executables.
Re: Writing "/etc/hosts" breaks the Substack editor
#204Earlier quoted context omitted.
I don't get why you'd have SQL injection filtering of input fields at the CDN level. Or any validation of input fields aside from length or maybe some simple type validation (number, date, etc). Your backend should be able to handle arbitrary byte content in input fields. Your backend shouldn't be vulnerable to SQL injection if not for a CDN layer that's doing pre-filtering.
Because someone said "we need security" and someone else said "what is security" and someone else said "SQL injection is security" and someone looked up SQL injections and saw the word "select" and "insert". WAFs are always a bad idea (possible exception: in allow-but-audit mode). If you knew the vulnerabilities you'd protect against them in your application. If you don't know the vulnerabilities all you get is a fuz…
Re: Writing "/etc/hosts" breaks the Substack editor
#205Earlier quoted context omitted.
While the password recommendation stuff is changing (the US government updating it guidelines last year), it’s generally best practice to not share passwords which itself implies using a password manager anyway which makes the whole “long passphrase” vs “complex” password moot - just generate 32 lowercase random characters to make it easier to type or use the autogenerated password your password manager recommends. T…
There's also login passwords, and depending on how many systems you have to log into, these can be quite numerous. There are some attempts to address this with smartcards and FIDO tokens and so on, but it's not nearly universal yet. At least SSH keys are common for remote login nowadays, but you still need to log into some computer directly first.
Re: Writing "/etc/hosts" breaks the Substack editor
#206Re: Writing "/etc/hosts" breaks the Substack editor
#207Does it block `/etc//hosts` or `/etc/./hosts`? This is a ridiculous kind of whack-a-mole that's doomed to failure. The people who wrote these should realize that hackers are smarter and more determined than they are and you should only rely on proven security, like not executing untrusted input.
How would that be hard? Getting the absolute path of a string is in almost all languages stdlibs[1]. You can just grep for any string containing slashes and try resolve them and voilá Resolving wildcards is trickier but definitely possible if you have a list of forbidden files [1]: https://nodejs.org/api/path.html#pathresolvepaths Edit: changed link because C's realpath has a slightly different behavior
Re: Writing "/etc/hosts" breaks the Substack editor
#208> This case highlights an interesting tension in web security: the balance between protection and usability. But it doesn't. This case highlights a bug, a stupid bug. This case highlights that people who should know better, don't! The tension between security and usability is real but this is not it. Tension between security and usability is usually a tradeoff. When you implement good security that inconveniences the…
Re: Writing "/etc/hosts" breaks the Substack editor
#209Earlier quoted context omitted.
It's a relatively recent change, too. Transition from "the executives and managers mostly came up through 10-25 years of doing 'lower' jobs in the company, and very much know how the business actually works" to "we hire MBAs to those roles directly" was throughout the '70s-'90s. Finance and business grads have really taken over the economy, not just through technocratic "here's how to do stuff" advice but by personal…
They're taking over veterinary clinics too! The biggest owner of veterinary clinics is Mars inc. the candy company!
Re: Writing "/etc/hosts" breaks the Substack editor
#210Earlier quoted context omitted.
I wish IT teams would say "sorry about the password requirement, it's required by our insurance policy". I'd feel a lot less angry about stupid password expiration rules if they told me that.
Sometime in the past few years I saw a new wrinkle: password must be changed every 90 days unless it is above a minimum length (12 or so as best I recall) in which case you only need to change it yearly. Since the industry has realized length trumps dumb "complexity" checks, it's a welcome change to see that encoded into policy.
This is such a bizarre hybrid policy, especially since forced password rotations at fixed intervals are already not recommended for end-user passwords as a security practice.