My work has us call a helpdesk which verifies our ID (based off the number we’re calling from and other info) then gives us a one-time password to reset all our login info
- 0 Followers
- 0 Following
- 2 Posts
Well to be fair, FBI would tap whatever VPS you use to host your email server and get your info from them. Email is not secure.
The assignment requires the database contents itself to be encrypted, not just where its stored, unfortunately.
Best Practices for Encrypted Search
Best Practices for Encrypted Search - Lemmy.World
Task I’m working on my final project for school, we are supposed to make a web app of our choosing and there has to be specific features in it. One of it is all data must be encrypted, and the other is that we have to have a search functionality. My app (A customer support framework) has a ticket functionality where customers can submit help request tickets, the contents of these tickets need to be encrypted at rest, at the same time admins need to be able to search contents of tickets. Current Plan My current plan is to store an AES-256 encrypted copy of the message message.content to meet the encrypted requirement, and also store a tokenized and hashed version of the message message.hashed to meet the searchability requirement. The tokenization/hashing method will be: - strip the message to alphanumeric + whitespace ([a-zA-Z0-9 ]) - tokenize by splitting the message by whitespace, - SHA-256 each token, - rejoin all the hashed tokens into a space seperated string and stored in the message.hashed field. Thus this is a test string becomes <hash of this> <hash of is> <hash of a> <hash of test> <hash of string> When the user searches their search string goes through all of the steps in the tokenization/hashing method, then we query the message table for message.hashed LIKE %%<hashed string>%% and if my thinking is right, we should be able to find it. Concerns - Statistical analysis of hashed tokens - I really don’t see a way around this, to make the string searchable the hashing needs to be predictable. - message.hashed field could potentially be huge, if each word is getting a SHA256 hash, a large message could result in a very large hash string - maybe we just store the last 4 of the hash? - This would increase collisions, but the likelihood of multiple last 4’s colliding in a given search string should be pretty dang small, and any collisions would likely not be valid language. I’m interested in hearing everyone’s thoughts, am I being logical in my reasoning?
Government Surveillance on Chinese vs US made phones
Government Surveillance on Chinese vs US made phones - Lemmy.World
Question that I’ve been mulling over recently: My threat model dictates that I’m more likely to be surveilled by the US government than by the Chinese government. We can also assume that the Chinese government is not going to cooperate with the US government in any investigations of potential activist activity. Would it not be best, then, to use a Chinese-made phone that, even though we know that information is going to China, we can also assume that any backdoors in the system are unknown to the US Gov? I’m interested in everyone’s take on this.
Look into Tailwind CSS and Alpine.BS for some pretty uncomplicated foundational level systems to build off of