• 0 Posts
  • 22 Comments
Joined 1 year ago
cake
Cake day: June 20th, 2023

help-circle




  • The TSA press office said in a statement that this vulnerability could not be used to access a KCM checkpoint because the TSA initiates a vetting process before issuing a KCM barcode to a new member. However, a KCM barcode is not required to use KCM checkpoints, as the TSO can enter an airline employee ID manually. After we informed the TSA of this, they deleted the section of their website that mentions manually entering an employee ID, and did not respond to our correction. We have confirmed that the interface used by TSOs still allows manual input of employee IDs.

    TSA: lalala i can’t hear you, everything is fine, no issue here








  • This. For example, if you have a DNS entry for your DB and the TTL is set to 1 hour, an hour before you intend to make the changes, just lower the TTL of the record to a minute. This allows all clients to be told to only cache for a minute and to do lookups every minute. Then after an hour, make the necessary changes to the record. Within a minute of the changes, the clients should all be using the new record. Once you’ve confirmed that everything is good, you can then raise TTL to 1 hour again.

    This approach does require some more planning and two or three updates to DNS, but minimizes downtime. The reason you may need to keep TTL high is if you have thousands of clients and you know the DNS won’t be updated often. Since most providers charge per thousand or million lookups, that adds up quickly when you have thousands of clients who would be doing unnecessary lookups often. Also a larger TTL would minimize the impact of a loss of DNS servers.



  • I have a coworker who always forgets TTL is a thing, and never plans ahead. On multiple occasions they’ve moved a database, updated DNS to reflect the change, and are confused why everything is broken for 10-20 minutes.

    I really wish the first time they learned, but every once and a while they come to me to troubleshoot the same issue.






  • I’m always suspicious of apps which setup a local web server to accomplish some basic task. When Zoom did this, it was a security nightmare.

    Just based on the screenshots, DroidCamX sets up a local webserver on the phone, and then the video is accessible on the local network (for example: http://192.168.0.17:4747/video). This means anyone on the local network can access the webcam, which in an office or school setting, might be disastrous. If a coworker were in a conference room using this app, a malicious coworker could use this to spy on the meeting surreptitiously.

    However it’s implemented in the OS, a basic requirement is that there is some authentication to link the phone’s camera to the computer, and that the video is encrypted in transit, to avoid man in the middle attacks.