TheFinalDraw's comments

The company I work for has used it as a relatively simple method for implementing mutual TLS (mTLS) for legacy apps or systems for which it would otherwise be annoying or more difficult to integrate mTLS for, or which doesn’t support mTLS with custom trust store.

Schmidt Ocean Institute (which owns/operates Falcor (too)) is an awesome nonprofit supporting a lot of really fascinating and impactful oceanographic and environmental research. One of my favorite oceanography documentarians, Leo Richards, produced a truly beautiful video for Schmidt Ocean Institute and put it up on his YouTube channel, Natural World Facts, which I highly recommend for anyone with an interest in the ocean or scientific research in general: https://youtu.be/Uh3fNYVwDXM?si=QnzFTJFJ5hIhXWoJ

How would you say your service stacks up against something like TailScale (https://tailscale.com/), which seems to solve the same problems but with end-to-end encryption and without the need to setup separate OAuth2 proxies? Where does ShareWith really shine and make things more easy/fast/secure/scalable/better than competitive solutions?

I get your points, but I disagree with your contention that the fact that all users of the system used a shared username and password doesn’t complicate the case. We’ve established that an IP address is not strong evidence for identifying an individual. IP address != authentication. What _could_ have established strong evidence tying the alleged unauthorized access to an individual’s identity would have been _actual_ authentication of the _specific_ user. But they don’t have that, either, since they shared one set of credentials.

You said, “they have an IP address which points to a specific one of those users,” but that’s not actually the case. They have an IP address which has somehow been related to the accused (though how is unclear to me since you note above there’s no linkage of IP/customer/date) — maybe they know she sent an email from that IP address at some point around the time of alleged crimes. But in any case, without providing evidence that the IP address is _only_ associated with the accused, and _not_ with any others with similar opportunity and motive (for example, any others with access to the shared username and password who might want to access the data for similar reasons, or wanted to frame the accused for hacking and put an end to the her very public/politicized efforts), then they don’t really have strong evidence of anything - basically only enough _not_ to rule the accused out of the probably large pool of possible suspects. How many other current or former employees had access to the shared username and password? When were they last changed? How many others who _weren’t_ ever authorized to access the system but could have compromised/gained access to these credentials since then? How many times have they been written down and left on a sticky note in some public or semi-public place? Do they ever have controls in place to prevent guessing/brute forcing the credentials (with one login for shared between all users, automatic account lockouts or resets seems very unlikely).

Hey! A thing I can actually help with! I put together a PoC of exactly this when I had the same idea a couple years ago. Here's a basic generic example I put together at the time, that also defines interfaces for other policy directives (e.g. min length, etc.): https://github.com/milo-minderbinder/policy/blob/master/src/...

I'll add docs and updates if people give a shit. The passwords.dat file in the resources folder is the top 1m most common pws that I compiled from a number of lists available at the time.

I implemented a redis-backed instance of the above common-password bloom filter in a sample Spring app which I was using to show off some features of spring security to a dev (I work in AppSec). You can see the policy and redis config here: https://github.com/milo-minderbinder/spring-ref/blob/indev/s...

And you can see an example of how to wire it up to a Spring Validator here: https://github.com/milo-minderbinder/spring-ref/blob/indev/s...

And you'll find where it's registered as a bean in the SecurityConfig.java file in the config dir with the other Spring java-config classes.

If you want to run it, I dockerized the whole Shebang with docker-compose a whole back, which should be easy to run: https://github.com/milo-minderbinder/docker-spring-ref/tree/...

Hope any of this was meaningful to literally anyone in literally any capacity haha

I love PlantUML! After a coworker introduced me to it at my old company, it quickly became my tool of choice for putting together security diagrams (I'm an AppSec engineer). I found it particularly helpful for this use case because it made diagram re-use, and updating existing diagrams when architecture changes are planned, extremely easy. We also used Confluence, for which there is a PlantUML plugin that allows you to insert your UML markup directly into a doc, which is then rendered by Confluence when someone views the page. I threw together a set of macros and sprites for AWS architecture and deployment diagrams, which I've put on GitHub[0] for anyone who finds it useful. Eventually planning to upload a fork I wrote that generically (and much much more efficiently) generates the templates and sprites for other services and products besides AWS.

[0]: https://github.com/milo-minderbinder/AWS-PlantUML