77 karma · joined August 7, 2020
Which is in and of itself a security risk. Not only can the length of the redaction give an estimate on the length of the password, but for variable width fonts, could even rule out many passwords using pixel measurements between the text on either side.
Recently I had a use-case where I wanted to re-use some data from a defined variable (list of objects) in a second module, but the format had to be different. In python I would have done something like new_var=[{a:i['a'], b:i['b']} for i in old_var], but apparently that is impossible in ansible. The best solution I was able to find after lots of searching was to to pass new_var to a jinja2 template which would render new_var as text, then run that through a json interpreter and set that as new_var. Absolutely rediculous.
It astounds me that a tool BUILT on python lacks any semblance of python's biggest feature, list comprehension.
Which is why the #1 preventative step taught in Canada (where we also have large bears and moose) is to be noisy. If the Bear, Moose, Deer, etc can hear you from a decent distance, they'll get well out of your way before you even know they're there.
I've been camping since before I can remember (literally) and the only "protection" we bring is mace and bear bangers (basically tiny fireworks without the lightshow). We've come across bears a number of times, but never had to use either. Just talk loudly and make some noise, and they just wander away.
I think the reason so many attacks happen to hunters is because they're trying to be stealthy and end up sneaking up on them (whether on purpose or or not), which is when they are dangerous.
I don't know how you can possibly establish a seasonal trend before we've even observed it for a single seasonal rotation.
If a bug is found in a non-NAT firewall that prevents it from blocking a packet for some reason, you have a routable address from the outside that you can send packets to. If a bug is found in a NAT firewall that prevents it from blocking a packet, it's very difficult to tell the router which internal address to route the packet to since the IP header only holds 1 "TO" address and by necessity, that's the public address of the NAT firewall.
There are of course some edge cases (double-headers, being on the same L2 network as the firewall, etc), but for most cases, the fact that the internal network is on IP addresses that won't route to their public interface (the NAT firewall) is in and of itself a layer of protection.
Personally, I think this trade-off is worth it in the long run, but it's simply not correct to claim they are equivalent when router firmware bugs are still discovered on a regular basis and consumer network equipment rarely gets security updates (and it's even rarer for consumers to install them).
This means she'll have to either send an IPv6 header or an IPv4 header with a false or blank IPv4 from address. If she sends an IPv6 packet, Bob's IPv4 network stack won't be able to understand it and drop the packet. If she sends an IPv4 packet with a blank or false IPv4 from address, Bob will receive the packet, but won't be able to send a response.
And that government also certainly has much less legal restrictions on tracking you since you're probably not their citizen. Unless you VPN to a node in your own country, in which case, they're just tracking you at a different exit point.
Whenever a request came in for something regarding the system, I would have to force myself to sit down with one of the other admins and walk them through making the change to close the ticket. It took 3-4 times as long to do the work that way, but after a few weeks, I could start assigning some tickets to them directly and eventually the time savings exceeded the expenditure and I could go back to big-picture planning.
It's a hard lesson to learn the first time, but worth the pain of going through.
I've regained all of the extension motion and probably 70% of my retraction motion (moving toes towards knee), but only about 30% of the muscle strength. Unfortunately it still swells up after long periods of standing or hiking but I'm rarely able to crack it anymore, and really wish I could on those bad days.
> Yes, definitely don't put secrets in the Dockerfile itself. I'm curious if there are reasons not to use a .env file though?
Environment variables are a terrible place to store secrets, regardless of whether you're using docker.
Environment variable values get dumped all over the place. /proc/*/environ, docker inspect, /var/log/..., core dumps, error messages, info pages (phpinfo), etc. Also, unlike file handles and secrets services (hashicorp vault, etc), every child process inherits all of its parents' environment variables, greatly increasing the attack surface.
common info pages (ex: phpinfo), core dumps, debug errors and logs are notorious for containing them. And those aren't even counting the ways a malicious actor can persuade a program to provide them.
Obviously software written for use in medical devices and banking systems should be held to a higher standard, but the same can be said for other licensed professions. A plumber installing a fire suppression system in a 50 story high-rise would similarly have their work held to a higher standard than someone setting up a rain barrel for their garden.
Personally I find the quality and vetting process of software designed to be installed on the same device that most people use to manage their online banking and carry on their most intimate conversations (often using said software) to be so low as to be considered criminally negligent by the standards of any other respectably industry.
For example if you have a home network and a testing network, you could have one on home.example.com and the other at lab.example.com, in which case your servers would be server.home.example.com and server.lab.example.com. If you use DHCP on those networks, you simply set the domain and search-domain options and you can just enter "server/" on the devices that moves between them.
You only need to register example.com with a registrar, then you can use whatever subdomains you want wherever you want.
As the person often tasked with evaluating, approving and deploying software, a page like the one linked to in this article can turn a multi-day review process (or weeks if I have to keep asking their sales people to relay questions to the technical team I'm not allowed to talk to and then relay back half the information they think they understood from said technical team) into a couple of hours.
A) some kind of secret that only the server knows that the client can verify in order to ensure it's not trading nonces with the MITM.
B) A way for the client to ensure that the nonce isn't being passed through a second tcpcrypt session between the MITM and the server with the connection being in cleartext between the 2 tcpcrypt streams.
Currently the best supported method of implementing both A and B is certificates, which means you may as well use TLS.
For example, if you buy "example.com", just set your public DNS (assuming your registrar provides one) to resolv it to 127.0.0.1, then add your internal hostnames and IP addresses to your internal DNS. If you do it that way, "my-server.example.com" will simply fail to resolve unless you're on your internal network and you don't have to worry about any issues with using the reserved *.internal domain.
In more dynamic environments, the config may have the domain as its own setting and each service as just the hostname, but the software must combine them before use, or better yet combine them in the config if variable expansion is possible in the config language they are using (ex: db_server="db-01.${domain}" with domain being defined near the top).
If you have a door lock that accepts "lock", "unlock" and "report status", a MITM attacker only needs to capture the encrypted & signed "unlock" command, then replay it later.
Many workarounds were developed to mitigate this such as random values, incrementing values and timestamps, but most were found insecure. Challenge-response systems with a short validity period are one of the better systems in use, but require bi-directional communication which can make some products (ex: garage door openers) more expensive.
I know it's not perfect yet, but the better and better it gets, the fewer reasons Microsoft is giving people to stick with Windows. I wouldn't be surprised if Microsoft stopped selling the local version in a few years.