Our policy is that we minimize the storage and use of any secret material.

In fact, we don’t even have logins into your servers!

We also validate that the public key you are uploading is an actual public key through a simple string check and warn you if it looks like whatever you’re uploading isn’t a public key.  We recommend RSA ssh2 keys but also accept DSS.

To do the job, we only need a user’s public key, so we also don’t currently generate key pairs. I’m not so sure that’s such a good practice, anyway. It’s convenient, but it doesn’t promote safe/secure key education and also requires the vendor to hold your private keys, even if only for a limited period of time. Private keys should be just that. Even worse, keys generated in a virtual server (i.e., an EC2 instance) may not have sufficient entropy.

Userify’s mission is partly educational:

2.  To help developers, admins, and non-security-types get up to speed with the awesome capabilities of SSH as well as learn how to use it securely.

We definitely might add automatic key rotation, however, which would require that we generate and know your key, at least temporarily. (However, right now, you can easily rotate your key right in the console with Userify!)

The huge advantage to our scheme….

If Userify was ever completely compromised — and even if it stayed compromised — (like if someone could sniff the TLS traffic or spoofed the SSL certificate and was able to maintain a MITM attack), any data loss would be minimal.

We only have public keys. Even your web password is salted and hashed with SHA-256 (certified for Top-Secret Classified materials) right in the web browser before they even get to us!  Even if our password database was compromised, those passwords couldn’t be used anywhere else and the plain text of those passwords would only be accessible through brute-force (which for SHA-256, as you know, would pretty much be fantasy at least in our lifetime.)

In terms of security algorithms, we store salted double-hashed SHA-256 passwords which are used to log into the web interface and public keys only. All communications, both server-to-server and user-to-server, takes place through TLS 2048-bit.

From a chat session…

this is a general design principle: Do as much as you can in the browser.

the only way to do that is to have a solid per-resource security model, of course.

this means now that we can build EVERYTHING in html5 and use the server for data management only — exactly how it should be!

now the “server” can be many servers, without using sessions or shared state. the cloud.

if one server dies and its hard drive collapses, no worries! your session is maintained in the browser, NOT using a cookie linked back to a PHP session id

This is called “state” — and it means that what state things are currently in (what actions are being performed, etc) are all being tracked in the application, NOT in the server.

This is a key part of Representational State Transfer (ReST) — state lives in the browser while the application is running, NOT on the server. There is no app running on the server… just data being stored and handed out. Long-running jobs, where required on the server, should be managed with scalable queues and short-running transactions should be used to communicate with them.

This is the foundation of Single Page Apps. For instance, wordpress is mostly an app that runs on the server. twitter is mostly an app that runs in the browser (in the client). This is not to say that an app like wordpress can’t be restful — but if it uses cookies to maintain a session ID that links back to state stored in a session database, then it’s not RESTful.

if you click a link in wordpress admin, it takes you to a different page, generally. In twitter, you’re always on the same page. once it’s loaded, only json is sent back and forth. Either way can be RESTful.

You’re already very familiar with this obviously — what I’m saying is that REST has very specific rules but they’re all wrapped up in a few general principles. (Side note: Single Page Apps that download content via AJAX often have poor SEO.)

For example, principle #1: state is managed on the client. If you want to store state between sessions (between application runs), either write it to the server as just another file or stick it in a cookie on the client (or other local storage like IndexedDB or HTML5 LocalStorage or whatever). State should be handled in the client and, as needed, conveyed completely in the transaction — if you need to connect multiple transactions, provide the server with links to any other resources that it needs to do its job. Why is this? Managing state on the server side does not scale: it adds latency and risks lost transactions.

principle #2: all requests should be short and sweet. No long running processes. Chat sessions should be polling the server for new updates, not just opening a long HTTP (or websockets/COMET) connection and keeping it open. (btw, Websockets/COMET is generally not RESTful.) The exception, of course, is long-running data transfers (such as file xfers)

principle #3: pass authentication credentials with each request. This seems crazy, but not if it’s delivered via SSL. Session timeouts can be handled with HMAC. This derives from principle #1 and #2: do NOT pass a session ID or something that requires you to go look up in a database to figure out what stage you are in a transaction. State should be handled in the client and completely conveyed in the transaction, if required. Always design around that. State lives in the browser, not the server.

Tabs are evil and you should never use them.

In other breaking news, researchers at CERN discovered that four spaces is the correct tab width.

Read more →

Amazon Web Services S3Here’s how to create IAM roles using CloudFormation.

After defining the role and creating this CloudFormation stack in your VPC or EC2 network, you can refer to EIPIAMinstanceProfile in other CloudFormation templates or simply manually choose this role from the list when launching a new instance.

If you’re not familiar with CloudFormation, using this is simple. Save the text below to a text file on your system, go to the CloudFormation tab in the AWS console, and Create a new stack. Name the stack anything you like and upload the text file. Don’t forget to check the box that says “I understand this stack may create IAM roles!”

 

Read more →

Amazon Web Services S3

Achieve phenomenal scaling heights with S3 — trillions of keys, millions of IOPS with a simple key naming trick!

If you take any pseudo-random hash such as any fast hash or an insecure cryptographic hash like MD5 (built into most languages such as Python) of any key and just take the first few characters of it — between one and four — and prepend them to your S3 key, then you can achieve millions of operations per second and over a trillion unique keys in your bucket.

Read more →

German Tank algorithm and statistical analysis

German Panzer III Tank from World War II

This statistical method was used to correct conventional intelligence estimates of German tank production in WWII

It offered extremely accurate corrections from the ~1400/month estimated from conventional intelligence, down to the correct number of ~255-256/mo and also a highly accurate number of deployed tanks at any given point the war — and, not only that, but to offer continually updated numbers throughout the war.

What’s amazing is how close the estimation was… usually within a single tank or two against the actual German numbers after the war. Conventional intelligence is anecodotal and anecdotes are not data.
Read more →

Outside of continuous integration strategies, deployment of new code into production typically involves multiple stages and environments, such as development, testing, staging, QA, and finally production.

Read more →

southwestDevelopment writes code (often rigorously adhering to agile or lean development methods) and then pitches it over the fence into production.

Sure – let the ops guys handle it. We’ll use puppet or chef and just get it into production fast and clean, right?
Read more →

studio

Buy land, son, they ain’t making it any more.Will Rogers

Especially on the low end, one of the biggest costs in the VPS or cloud server space is the cost of an individual IP.

That’s certainly the case for IPs. (well, IPv4, but as yet those are all anyone really cares about commercially).

The problem really isn’t that IP’s have some sort of built-in intrinsic value on some mythical black market. The problem is just that since there aren’t enough of them in usable blocks, the value of them in some fashion shoots up. They’re a commodity in limited supply — so basic economics kicks in.
Read more →

Let’s say that you need to backup a remote server’s /etc directory.

It’s most secure when backups pull, not push.  Your PRIMARY box should not be able to login to your backup box to prevent disruption of the backup data. Keep in mind that if someone gets to your BACKUP box, they can easily wipe out your primary, but your BACKUP box can be sitting in a highly secured environment without outside access.

The reason why this tip is important is because you should have already disabled remote root access by setting PermitRootLogin no in /etc/ssh/sshd_config on both servers. However, how can your backup server elevate its privileges on the primary server so that it can read the files to be backed up?

Read more →