jvdongen

For one thing, AFAIK, Alice can be sure that Bob's 'pad' is the only copy in existence because no one can copy Bob's 'pad' without destroying the entanglement.

For a 'regular' one time pad this is not the case. Someone could have copied it and both Alice and Bob would be none the wiser until it's too late.

One-time pad based encryption schemes are theoretically unbreakable - one of the things (the thing?) holding back wide spread adoption is the difficulty of proper key management. This has the potential to solve that issue.

Not really - if a one of the CDN's mentioned develops a security issue my sites are among the 26.6% that are unaffected.

Indeed - that is exactly what went wrong in the case of our unfortunate Wired reporter.

Also, there's a big chance of course that if someone has lost the password to a services he uses more or less regularly, he'll also not be able to remember the password of a service (the secondary mail account) he uses almost never ...

Indeed - that was the whole idea. But may be I'm becoming old fashioned ;-)

Also, if something like this gets implemented by a few (or even a single) high profile site being someones 'password buddy' will probably quickly become an accepted, may be even honorable, thing.

That can't work - how would they identify the service using them? Ip address is useless for this purpose and other identifiers ar either not available or very easily spoofed and thus equally useless. If somebody gets hold of the application specific password, he'llbe able to use said application.

Indeed there is no right or wrong in thus case. Just different shades of grey. The scale you're aiming for is an important factor though (and I don't know what you're aiming for so I provided ours for context). And perhaps even more important is the ratio between tenants and actual users.

In all cases there is work to do of course - I've just found that the 'one db per tenant' model allowed us to re-use more exiting infrastructure than the other models. For us that's a win. As always the devil is in the details - some of which do not become clear until after you've run into the corresponding devil.

With respect to security/isolation consider the following.

Case A: one schema per tenant, one db user shared across all tenants. Anyone with the ability to manipulate going to the database (e.g. a hacker via a sql injection vulnerability) can access all schema's and all tenants data.

Case B: one db per tenant, one db user per tenant, one app process per tenant running under its own os user. In this case an attacker is far less likely to be able to access any data from tenants other than the one to whom the compromised process belongs to. Of course if the processes of other tenants are also aproachable by the attacker it is very much possible that the processes of other tenants will be compromised through the same vulnerability. However in our situation that is not the case (well, I should know better: it will be very difficult for the attacker) , hence we benefit from the extra isolation.

Your assumption that Postgresqls authentication or even OS level authentication provides extra isolation is wrong - unless you use one db user per tenant and set permissions carefully. But as stated before, in that case you better double check if you still benefit as much from the schema-based multi tenancy as you may think. And even then the level of separation is still lower.

What isolation level you need depends on your audience of course but from a security point of view I do not consider a schema based approach as much better than 'all tenants in the same table with a tenant_id field'.

We actually do automate as much as possible (small team, lots to do). We've a Fabric script that sets up a complete new environment for a customer/tenant in one go. That includes creating and populating the virtualenv, creating a new database + database user etc. If the command is finished the customer basically is able to log in. And that script is actually only about a 200 lines of code or so.

The nice thing of Fabric is that it makes automating something hardly more work than doing something in a one-off fashion.

I actually have implemented a multi-tenant application based on Postgres 3 years ago and we have been using it in production ever since (for paying customers that is). As such I have some experience in this field and I'm actually in the process of moving (back) to a model where each customer has its own database (and application process). For context: I have a relatively low number of tenants (tens) which in turn each have mid-hundreds to many thousands of active users (the largest tenant has just about 10k active users).

Unless you think you will have many hundreds or thousands of tenants (!= users) any time soon, I'd advise you to stick with one db per tenant.

The reasons for backing out of the use of schemas for multi-tenancy are for me:

* on a smaller scale (with regards to number of tenants, not users) it does not really offer any significant benefits in resource usage over one db per tenant, which makes the following reasons significant:

* lack of isolation - unless you use a separate database user with carefully set permissions for each customer it is possible to access each schema from a single compromised application process. If you do actually use a separate db user for each customer, one of the benefits of using schemas as opposed to separate db's disappear (you can no longer share db connections/db backends across requests from different end-users so the number of concurrent database connections increases).

* complexity - multi-schema use is usually not supported by default in common web frameworks and related tools. I use Django and had to create a custom db driver (and leverage thread-local storage) to get any sort of transparent support for multi-schema use (and especially in this case you want transparency for your developers - otherwise risk of isolation failure increases to the same level as with the 'one db/tenant_id in table' approach - see previous point). Also backup/restore becomes more complicated. And Django's management tools (the manage.py script) had to be taught a new trick. And South, the schema migration tool had to be ... You get it I guess. It works - sure, but took quite a bit of work to get right and there is always the risk that future updates to any standard packages used break it again. I'd rather not have it.

* one schema per tenant implies also one application process for all (or at least multiple) tenants. This again makes it more complicated to keep things secure and you'll run into some other issues as well depending on the requirements for your application.

One of those issues we've run into (not related to the database) is that we're in the position that we can definitively benefit from a 'one source code base for all' but still have to be able to customize our application per tenant with respect to the specific wording of certain aspects in the user interface and that in multiple languages. In the current setup (one application process for all) it meant that we could not use Django's native i18n machinery. Building an alternative (with proper version control in this case) was not as much fun as you may think and basically a mistake. In the setup we're migrating to we can leverage the native i18n features of Django (and git) for this job.

So where we're going now is:

* one virtualenv per tenant, with a dedicated Django project for each tenant (the Django project does not contain the actual application code, only settings and if the need arises customized .mo/.po files.)

* one application process per tenant (I use uwsgi with emperor mode for this)

* one database per tenant (hosted on a Postgresql master/slave pair)

The resulting setup is easier to maintain and reason about than the current setup and my testing so for shows that resource-wise it does not make a significant difference. There is of course a bit more disk usage and a bit more memory usage. That is mostly because of the extra copies of the application code I need to keep around on disk and in memory - but that is all together a relatively minor bit of the total disk and memory usage so percentage wise it does not really make a difference (at least for us - is probably very situation dependent).

Something I'd been worried about was the number of concurrent database connections. But after some testing that fear turned out to be unnecessary as even under very high load the number remained within manageable bounds.

EDIT: formatting.

In principle you could already achieve that by binding a session (and corresponding cookie) to the client's IP address. No big deal.

Problem you may have is that some clients are behind proxy farms and can arrive with different source IP addresses within the scope of a single session.

If you do not bind the 'server-assigned-per-connection ID' to an IP address they become just as 'leakable' as a session cookie.

Keeping your software up to date is great advise. However I do not entirely agree with the statement that security through obscurity never works. It can never work alone - true. But in combination with other measures it can be a great help.

And with respect to the point cshimmin makes, there is some merit to it. Yes nearly every piece of software, open or closed source is bound to have vulnerabilities. However, the chance of someone taking the time for finding and exploiting a moderately hard to find bug (not referring to a run-of-the-mill sql injection) in a piece of software I've written myself and I'am the only user of is vastly lower than in case of a popular piece of open source forum software (to some extend depending on who I - the only user - am of course).

A skilled locksmith or someone with a serious interest in locks will have no problem [1] to open your front door without any damage using a lock pick tool [2]. If there's no need for said lock to survive, a selection of power tools make it even easier.

[edit] Which is not to say that cars should be easy to pry open of course ...

[1] in most cases, high-end specialized locks can be an exception. [2] see http://www.lockpicks.com/ for examples.

Thanks for your clarification. Phrased this way I tend to agree with you.

I'm not sure I read your final remark correctly. Do you mean to say that using Skipfish or sqlmap has no place in a professional pen test or that a professional pen tester should not subject his clients to the raw results from said tools?

The latter I agree with, the former I don't. Any automated security scanner has its shortcomings - combining the results of various scanner products generally has a positive effect upon the quality of the test. I've often been in a situation where one tool (commercial or otherwise) indicated or hinted at a vulnerability while all other tools (commercial or otherwise) used did not indicate anything.

I'm a 'lefty' and write with a fountain pen using Parker's Quink - a fairly fast drying ink. Works remarkably well.

I do not expect software pricing to match the marginal cost to the supplier per se. And you're right that pricing in general is done in relation to what's the customers perceived value.

However, I disagree with your first statement. Lets take Highrise pricing plan as an example. For the 6 user plan you pay $24/month - which comes down to $4 per user. For the 15 user plan you pay $49 - about $3.26 per user. So my total cost of course goes up with usage, but not in a linear fashion.

You could also make that happen with the $x/user/month scenario, but that gets probably rather complex without ending up with tiers again.

I've some reservations with regards to your pricing model. Say when I go from 3 user to 4 users I pay 33% extra. At basically no extra cost for you as a supplier ... (the operational cost difference between 3 or 4 users is in the case of a CRM system negligible). That simply doesn't feel right.

The decision to require ISP's to block the Pirate bay is currently being appealed by the way. It's a judicial issue based on existing laws, not a political one such as the net neutrality one. And as long as the appeal is going on nothing is definitive.

Well, that kinda depends on how you define standard of living of course. We live very different and longer lives today as opposed to 200 or 1000 years ago. But on a basic day-to-day level, do you think you live a significantly happier and more fulfilling live than a random someone from a 1000 years ago?

If you are in the position to passively sniff the traffic, you're almost always also in the position to redirect and modify the traffic.

The only thing you're protected against with encryption sans authentication is passive sniffing. If that's all you care about, fine, do realize however how limited the protection is you gain.

I now see your 'PS' (perhaps added while I was adding my comment?) - however I cannot follow the argument you make.

IF you assume that MITM-attacks are rare, you probably also assume that traffic snooping is rare (which is after all a form of a MITM-attack). If that's the case, why use encrypted communication channels at all?

Security is never perfect - it always is about adding layer upon layer to make the bar high enough that the remaining number of adversaries becomes more manageable.

Spoofing a site that is not using SSL is trivial. Using SSL with public CA signed certificates significantly raises the bar. Not to the 'perfect' level, but enough to make a real difference. Not checking the server certificate throws you back to the 'trivial' level.

Not to pick on you per se, but this reasoning is often seen in relation to SSL (or encryption in general) and is dangerously wrong.

Encryption without identification and authentication of your communication partners is useless. You may very well end up with a very secure link with the wrong communication partner (google 'man-in-the-middle-attack').

I agree that the (public) CA system is a mess, however especially with machine-to-machine communication it is very easy to generate, sign and use your own certificates. And contrary to popular belief, self-signed certificates are not any less secure than public CA signed ones. Both have their own use-case though.

If someone cares I'll be happy to explain the above points in more detail.

I've noted that split as well - and wondered indeed if there is no middle ground. Recently it occurred to me that perhaps there is no real need for that middle ground.

The fact that Django comes with even more batteries included than Python itself does not mean you have to use each and every battery. And ignoring stuff you don't need is often easier than extending an even moderately complex 'middle ground framework' in a meaningful way without making a mess of it.

If I compare that to my own experience, that is exactly what I've started to do over time.

A thing I've become accustomed to is splitting my applications cleanly in 'front-end' (focus on interaction with humans) and 'backend' (focus on business logic, (persistent) state and interaction with other applications/machines).

For front-end applications I've no real need for a number of things Django offers (ORM, authentication/authorization mostly). For building back-end applications Django has even more bits I do not really need.

This lead to a situation where I asked myself 'what does Django still offer me? Is it not easier to use a more limited framework for either use case or gobble together my own frameworks from various bits and pieces?'.

For front-end applications I could've (and have tried to) build a framework-to-fit from various bits and pieces such as cherrypy, jinja for templating, babel for i18n, routes for routing, etc. However creating a solid working framework this way, with all bits working together nicely - and keeping up to date with the development of its various bits and pieces - is a lot of work. Just using Django an ignoring the bits I don't need turned out to be far easier, leaving more time spending on my actual problem.

And for building my backend-applications I don't need all the stuff listed above - I simply need a robust and reasonable fast networked server which can host my business logic. The 'minimalist' frameworks then offer just what I need without getting in the way too much.

So in conclusion: if you want to build something that is mostly logic with a machine-machine interface, the minimalist frameworks offer a solid foundation and you have no real need for all the extras a 'mega framework' or even a 'middle ground framework' offers you. If you want to build something that has to interact with humans, you actually do need most of what the prevailing 'mega frameworks' offer you and leaving out the bits you don't want is easy. Hence there is no real need for 'middle ground' frameworks.

Easy way out - if you estimated 3 days and it turns out to be 3 hours ... simply sit on it for 2 more days ;-)

Personally I would be delighted if the government hired (as in permanent, not by the hour) top-notch tech engineers to maintain their IT infra. It would most likely cut down IT costs enormously while at the same time making things running a lot smoother ...

And even if the IP address is unaltered - what will prevent the owner of the closed network from routing every http(s) request silently through a proxy on its way out to the Internet?

In a corporate setting in which you use a computer provided by your employer this will always be possible. You can do it by simply generating your own CA certificate and making sure every browser used throughout the company has it in its CA cert list.

Not sure it is such a great analogy. Driving is a fairly deterministic affair where you can just follow a proven recipe and obtain the desired result. It takes some skill, certainly. And so does running a business. But there is a major difference. In driving if you simply do what most other drivers do it will (mostly) result in success.

Running a business is far from a deterministic affair. It takes skills and the skill set is diverse. And on top of that you don't want to do exactly the same everyone else is doing. If you do that, what would be the point of running your own business. You want to do something different or in a different way. You'll always get at a point where you need to take a course that others may see as risky or unwise to get at your intended destination. And that bit, nobody can help you with. You've to experience it for yourself - including the bumps and bruises.

Having an experienced mentor can be a good thing for the more mundane aspects of running a business, but for the actual "running your own business" part, not so. In my experience actively seeking out a rich variety of sources of inspiration is far more important for that part.

The front-page of HN is a filtered list in and of itself. And I for one actually like the result.

Some people would like to see a different filter and thus create one, because they can. That is indeed not something you can, or should want to, prevent.

But the fact that some people create their own filters is not a motivation to not tweak the HN front-page filter in such a way that the front-page matches the intended goal (pg's goal in this case, presumably adopted by the majority of HN readers, more-or-less codified in the guidelines) as closely as possible.

Though not a bsd user myself, I'm glad to see this happening. A few extra security-minded eyes on the nginx source code can only make it better.

1. while true, PG has other features (e.g. partial indexes) which can make a big difference as well. Completely depends on the scenario. Sometime mysql will 'win', sometimes PG. No real reason to pick one over the other, unless you know that in your situation a particular feature is a real must-have.

2. use a connection pooler (e.g. pgbouncer), problem solved, good practice anyway, even with mysql

3. what (practical) edge do you see given the replication features in 9.1?