I fear it may be unfair to expect most end-users to apply this scheme appropriately and consistently, and therefore recommend that it be known as mustard.
I was thinking currying, as it is both spice-themed and analogous to function currying in that you take your base password, curry it with the secret to get the submitted password.
Horcruxes are similar to what emmanueloga_ has mentioned. Horcruxes were special things in which Harry Potter's lead antagonist, Voldemort stored parts of his 'soul', so that even if he died, someone cpuld revive him using the horcruxes. I haven't kept up with Harry Potter for a year now, so I might be wrong with respect to the exact definition.
> A horcrux is a plot device where the protagonists need 2fa to send a HUP or TERM to the misbehaving process.
Okay, I didn't literally LOL, but you did earn a really big grin and even a chortle. Well done.
BTW, I would totally read "Harry Potter and the Protocols of Security". Some of the "Methods of Rationality" fan fiction by Eliezer Yudkowsky nods in that direction (eg. the Death Eaters' opsec).
I think so, particularly if you've read Rowling's books and were annoyed by many of the protagonists and supporting characters for a variety of reasons.
If nothing else, "Methods" succeeds in giving agency to more characters, including the villains (not necessarily to their, or Harry's, benefit), and explores/tests the "system" of magic in more depth.
>> and explores/tests the "system" of magic in more depth.
I particularly liked the section where Harry is trying to find out how magic "works". He starts with the gross physicalities: the materials the wands are made of, the sounds of the recited spells. He ends up with the mathematics underlying physics, learning how to create new spells. He uses his new found knowledge to create a very powerful weapon spell he uses to kill a mountain troll. If you want to know how the spell works, you'll have to read the book. I highly recommend it. (I've read it more than once.)
I liked the exposure of the DWIMian (rather than strictly Newtonian) physics of flying broomsticks, although it should be noted that the DWIMian behavior is based on the physics of low-speed high-friction ground transportation rather than a sourceless 'intuition' the author blames.
I think these concepts are significantly different - as different as salts and peppers at least. Peppering helps protect against database access revealing password. Horcrux protects against password manager access. Peppering is stored on the server, but outside the database. Horcruxes are stored in the user's head. You could do both, one, or neither. Client-side peppering would be having part of your password outside of the password manager but still on your computer. If anything it's brain-side peppering.
> Peppering helps protect against database access revealing password. Horcrux protects against password manager access.
What is a password manager but a database of your passwords? Peppering is a token that is not in the database of passwords that needs to be applied for the password to be correct. Whether it's applied by an application, or a person doesn't seem relevant, as what is an application but a set of instructions a person could do carried out automatically?
I don't care what it's called, but I don't really see a difference in the scenarios you've outlined.
> Peppering is a token that is not in the database of passwords that needs to be applied for the password to be correct.
Well, typically a server only cares about verifying the user (still) knows a password.
A typical server (today) does not have a way to reconstruct the plain password, only a way to check if any given string matches.
A password manager, typically does have a way to supply the password.
Peppers and salts are typically manipulated by the server system, plain passwords are typically managed by the password manager.
In this case the password manager never sees the hocrux, and cannot leak it. A server will typically leak a pepper to anyone with access to ram (or access to a hw enclave, which is expected to be more difficult).
Frankly this has more in common with a 2FA approach with one factor being the password manager and the other your horcrux. I wouldn't call my phone authenticator app a client-side pepper.
SEEKING WORK | Full Stack Engineer specialized in Ruby on Rails and InfoSec | Paris or remote
I have 5+ years of experience with Ruby on Rails. I also have a diploma and work experience in Information Security (but I am completely open about working in other fields). Strong entrepreneurial mindset and happy to participate to my client/employer company at every level, not just technical.
I have experience in refactoring apps for easier maintenance and evolution, and in upgrading legacy apps (I have migrated an app from Rails 2 to Rails 5 without issues). I take extra care for UX and design when implementing new features, and try to maximise developer happiness by using the most efficient tools available (exemple: static type-checking with TypeScript instead of JS, etc).
Stack:
* Backend: Ruby on Rails, Python
* Frontend: ReactJS with TypeScript or JavaScript
* Mobile: React-Native
* Also: good knowledge of SQL, Bash, C, Electron, ..., and willing to learn Elixir
Note that domain fronting is not only usefull to circumvent Internet censorship, it's also used by malware.
With domain fronting, you can exfiltrate data from a company by making the connection appear to go to a legitimate google service (ex: drive.google.com), whereas it actually is going to a server hosted on google cloud services and controlled by an attacker.
Gotta take the bad with the good. Some governments act like companies and treat tools like Signal as malware. Another discussion can be had for citizen freedom vs employee freedom, but public network restrictions benefit all kinds of censorship. It's also another discussion worth having on whether one's need to monitor all data in/out of their company is worth giving that power to other who use it for wrong (mitm devices and TLS termination w/ custom device certs notwithstanding).
Google or another more privacy-supporting company could block domain fronting for everyone _except_ Signal, Tor, and similar projects, with some sort of application process. Blocking everyone seems heavy handed but fronting itself is ultimately a sneaky way around censorship rather than an intended feature.
So the decision on what apps can be domain fronted because they need to get around censorship lies with Google or another big company, what could go wrong here?
I mean the entire trick to domain fronting is that some large company, whose site no country would dare censor, offers up their infrastructure as a front.
Who else do you think should decide who gets to host content through Google's servers?
Google is not accessible to about 1.4 billion people because the single government of China "dares" to censor Google. That's close to 20% of the world's population.
I don't think companies nor governments should get to decide this at all. Information wants to/should be free.
I’m pretty sure you can achieve pretty much the same thing by just uploading encrypted exfil’ed data to actual legit Google Drive using OAUTH to programmatically access a throwaway account (to avoid possible CAPTCHA requirements for non-programmatic access)
lemonde.fr published an article [1] yesterday, in which they debunk this news. A seismologist at Southampton University says [2] that it's unrelated to the rifting.
In addition to the "minimalist" aspect, this image seems to offer better practices on a security level than official Debian images. From their README: "The images are built daily and have the security release enabled, so will contain any security updates released more than 24 hours ago."
> In addition to the "minimalist" aspect, this image seems to offer better practices on a security level than official Debian images
I'm skeptical about this claim. Almost every image built from the Debian official image begins with `apt-get update` before you can actually install anything, which means you will almost always have the latest packages at the time of building.
While not as small it is trivial to make an up-to-date debian base image (or Fedora/Arch) any time you want. If you care about security you probably don't want to use random unverified images anyway.
$ sudo debootstrap stretch mydebian http://mirrors.kernel.org/debian/
$ cd mydebian
$ sudo tar -c . | docker import - mydebian
Plus you can add files to the system before taring etc...
If you have significant work to do on an image a Dockerfile can often be far more complex than this method.
No offence intended and these terms are not tightly defined but I would call your imaged a 'baked' image.
My feeling is that I don't know how long a base-image will stick around. If ca-certificates is installed in my base image it may end up trusting revoked certificates.
IMHO it is better to know you need to install/bake in ca-certs from a trusted source than to having a built in, potentially compromised CA cert installed.
Baked images, which I use to reduce instantiation time, or 'golden' images that are immutable infrastructure tend to have shorter lifespans and the CA package is carried in the application dependencies and more likely to be up to date.
It is not intended that users will download this baseimage (although it is a supported configuration, you can use FROM phusion/baseimage) but, that this will be an image definition that users can easily rebuild and build off of it.
Step one in Docker competency is "do you know exactly where your image comes from, and can you rebuild it from scratch without trusting that some rando on the internet didn't put bad stuff in there?"
Step two is "ok, do you really actually build them, though"
This image has traditionally been based on LTS ubuntu, and if you look at the CentOS derived version that hasn't been updated since 2014 (pokle/centos-baseimage), they chose not to include ca-certificates or hardly anything else.
(I'm assuming that tianon/centos:6.5 does not install ca-certificates by default...)
I'm sure many people use FROM phusion/baseimage but personally, even as a maintainer, I don't. I'd change the image source to whatever upstream of Ubuntu I'm preferring today, and probably build that from scratch too. The value in this image is not that it comes pre-built, it's that the build is tested and supported. /side tangent
You can go ahead and explain what you think base image means then, because it's not obvious to me how this is different than that (and I'm a domain expert.)
A base image is an image that you're meant to build off of, it is not meant to be deployed as an application but as a base for your image. What part of what I said was disingenuous? I gave a link to some source code that I didn't write and provided a counter example, identifying myself as a contributor. What did you contribute?
Great misunderstanding of what I said, this is two in a row when considering the above, bravo.
What is wrong with your first comment is:
1. zenlikethat's comment obviously talks about base images in general, not about a specific base image ("...most base images...")
2. Your reply which disagrees with that is based on a very basic fallacy (there is a one base image which contains ssl so zenlikethat's claim is false!?)
3. Your example is a base image which you're a maintainer of
Considering (1) is obvious and (2) is a very basic fallacy nobody here should fall for, your comment seems like an intentional and unwarranted plug for "phusion/baseimage" instead of a valid and honest disagreement to zenlikethat's comment. (extra points for unwarranted plug of your domain expertise in immediate parent comment)
I'm supposed to provide examples that I am unfamiliar with?
Forgive me for misunderstanding your comment, but `"base image" != "baseimage"` did not have a great deal of substance to it, nor did it provide me with any insight about the topic.
I provided an example, to facilitate the discussion. So back to my last question, what did you contribute?
I couldn't find anything in the post that correlates the Debian updates with security notices (which is your main point). If a security advisory comes out every 2-5 weeks and Debian updates on the same schedule, then I don't see a problem. But the data is just not there.
(These have to be advisories actually affecting the image, not all of them)
Unfortunately, as many game creators, they seem to believe that everybody in the world has qwerty keyboards, which is not the case. Using the A, W, S and D letters does not make sense on azerty keyboards (up and down reversed). Why can't we use keyboard arrows to move?
Too bad, the game would have been really fun to play if controls were usable for me.
