Random Password Generator Tool

Sure, there are lots of random password generators out there, but how many of them are integrated with our very feature-rich open source code repository of tools that will help you to code against Active Directory, while also standing alone as a simple quick to use tool for a helpdesk?

Yeah, that's right, only 1 random password generator tool does that.  Get it and its open source code now: https://github.com/Securology/ActiveDirectoryServices/tree/master/PasswordGenerator

Coding for Active Directory: Quickly import Exchange Rooms or Resources

Do you have a copy of Visual Studio, a very rudimentary knowledge of C# .NET, and a need to import a list of Exchange Rooms or Resources into your Active Directory?

If so, check out a couple very simple example apps that can import .CSV files to knock out this frequent task:

https://github.com/Securology/ActiveDirectoryServices

Coding for Active Directory: Programmatically Get or Set Obscure Attribute Data in C#

If you are an organization of any size, chances are you have an Active Directory instance sitting around, and maybe some level of additional investment in Microsoft products beyond Windows on client machines and a couple servers.  And the more investment you have, the more value you will get from having relevant data in your Active Directory.  You may even have some developers on staff that write applications in C# or VB .NET.  Chances are, though, your developers won't understand or even want to understand Active Directory.

They may, however, be able and willing to code to a few random source code examples that float around on the web, but most examples are not very feature complete.  So it requires developers digging into the musty underbelly layers of Active Directory to learn how to get what they need.  Few will dig.

You could purchase an API, but the licenses may be expensive, and you may only want to read or set a couple of attributes on a user or group object that nobody else seems to have documented how to do well enough to satisfy your developers.

Or you could just send your developers to the new Securology GitHub repository to pull down a fully-functional, open source, non-restrictively licensed API to include in their projects to get up and going.

Maybe you just dealt with a large scale AD migration and you need to peel back the layers and extract user or group SIDs (Security Identifiers) or validate that SIDs from previous domains on imported objects are properly stored in the SID History?

Maybe you have a basic interface with your HR system, but don't want to shell out tons of cash to purchase a metadirectory tool like Identity Lifecycle Manager to move HR data like manager/reporting relationships around, but could really benefit from having that data in your Exchange, SharePoint or other application environments.

Maybe you need to set the user's employee number from your HR system on each AD user to identify the authoritative data source to satisfy an Active Directory Audit.

Maybe you just want to read or write the AD user's address, telephone, or even IP Phone number.

Maybe you have a mixed environment that also contains Unix servers and you need to set Unix attributes on the IT Unix Admin user accounts for a Unix SSO to AD product that you're using.

Maybe you'd like to programmatically setup Microsoft Exchange or Lync (Office Communicator) attributes?

Maybe you'd like a safer way to programmatically move or delete Active Directory objects?

Maybe you'd like an easier way to programmatically add or remove a user from an AD group?  Or maybe check if they already are in that group?

Maybe you'd like to populate your AD with Contact objects for business partners who don't need user accounts in your domain or forest, but so that they'll still show up in the Global Address List (GAL)?

Maybe you need a way to programmatically create an Organizational Unit (OU)?

Maybe you'd like to toggle an AD group from "Security" to "Distribution" and back again?  Or "domain local" to "universal"?  Or dump all of its members?  Or check if the AD group has no members?  Or set the "owner" of the group for audit/management purposes?

Maybe you'd like to prune back old computer objects?  Or build a report to show what Operating Systems are in your directory?  Or safely move or delete computer objects?

Maybe you'd like a way to expose the True Last Logon time of a user account without manually checking each Domain Controller and comparing times?  Or maybe you'd like a nice multi-threaded (and fast!) way of checking all Domain Controllers simultaneously?

If any of those are even remotely interesting to you, check out our extended version of Microsoft's System.DirectoryServices.AccountManagement namespace that we provide on GitHub.

Coding for Active Directory: Proxying Users into an AD-LDS Application Directory

In another IT Pro tip related to Active Directory, suppose an organization has an internal AD forest, but has a company policy that only paid personnel are to have accounts in that directory.  That's a fairly rational policy:

• If we pay you directly, then you're an employee, so you get an account
• If we pay you indirectly, then you're a contractor that we've hired, so you can also get an account
• If you pay us, whether directly as a consumer, retailer, or reseller, or indirectly as a consumer through a retailer or reseller, then you're a customer, so you probably should not have an account in our internal AD forest.

But suppose you have an application that needs to be built that will allow both employees/contractors, AND customers to access it, and you don't want to setup yet-another-provisioning process for granting and revoking access for employees and contractors?

Enter a common solution: Active Directory - Lightweight Directory Services (previously known as ADAM, AD Application Mode, a.k.a. an "application" directory).  This is a lightweight, LDAP only directory with less bells and whistles than AD has, but many Microsoft-centric applications can plumb right into it.

But to achieve a true Single Sign On for the internal AD users, the IT Admin must create either a UserProxy or a UserProxyFull object in the AD-LDS.  Both function nearly the same, but a UserProxyFull has additional schema data elements for storing additional contact data fields, which are generally handy for today's applications.

Under the hood, when an internal AD user connects to the application, an authentication request is passed to the AD-LDS, which looks up the UserID of the internal user, finds the User Proxy object, and then performs Kerberos authentication against the internal AD.  All other attributes, though, from contact data fields, to the group memberships that the UserProxy has, are separate from the internal AD forest.  In essence, nothing is automatically the same and it's yet-another-directory-to-manage.

Wouldn't it be nice if there was a way to build a service or application in C# .NET so that a configurable subsection of your organization's internal AD user community could automatically be provisioned and deprovisioned, complete with metadata updates, and maybe even rudimentary AD-LDS group memberships based on your AD data?  Why yes, yes that would be very nice.  

Wouldn't it be even nicer if the code was open source so we can take it, borrow it, and use it internally without a restrictive license?  Why yes, yes that would be very nice, too.

Wouldn't be even nicer still if this article linked straight to that source code?

Why yes, yes it sure would be nice.

Good thing we just did! 

Start synchronizing your Active Directory forest with your Lightweight Directory Services (AD-LDS) instance with this example solution in C#.

Active Directory Tip: Hitting Snooze on the Password Expiration Policy

The Active Directory Password Expiration Snooze Button

IT Administrators have certainly been in the tough scenario where a security policy mandates that passwords expire in X days, but there are constraints that make it really hard for the user account passwords to actually change.  For example:

• Dealing with service, application, or generic accounts and a strict constraint to not mark them as non-expiring (forever) passwords
• Dealing with rarely active human users who suddenly need to (on-demand) authenticate against an application, such as HR benefits open enrollment for employees who are not "information workers" (don't access computers).

There are a couple tricks for dealing with this without causing interruption.  Take note that these "tricks" may completely circumvent the letter and perhaps even the intent of the "policy".  But even with astute auditors, the intent of using these tricks will likely never get noticed. 

Or perhaps you are an auditor, and reading the details of these tricks will open up your mind to look for new events that signify lack of compliance.

Administrative Password Resets

If you know the password for the account in question, then simply perform a password reset with that password.  If you have never thought to do this before, this may at first seem counter-intuitive: after all, resetting a password with a password history rule turned on by policy will cause the password to change, right?

Wrong.  There are two ways an Active Directory password can change: 

1. The user initiates a password change event, in which they are required to supply the current password in addition to a new password.
2. The administrator with permissions on the UserAccountControl attribute of the AD user object can perform an administrative reset.

A reset by an administrator must support changing the password when the user is locked out and does not know the password, therefore, the administrator is not required to know the current password.

Also, a reset by an administrator does not enforce password history.  If it did, a rogue administrator could inadvertently learn the current password if the new password supplied by the administrator failed to reset due to password history requirements.  Sure, they just reset the password and could impersonate the user anyway, but that may not be the point: that user's password might be the same on a different (non-Active Directory integrated) application.

So, if you know the current password, perform a RESET and the password last set date attribute on the user account in the directory will update, effectively hitting the snooze button.

A More Clever Trick

But what if you don't know the current password for the account?  

In the scenario of a mostly-inactive end user community that suddenly need to hit an application (e.g. your company's HR system for annual benefits enrollment):

• there may be too many users to learn their passwords
• asking the user for their password is likely faux pas
• the user may not even know the password anyway (since it's been a year), and 
• resetting a large collection of users passwords to a standard/default that everyone shares is insecure
• and resetting individually unique passwords for an infrequent, on-demand access presents communication problems all of its own

So, what to do? 

You could disable or extend password expiration.  In Windows 2003 AD and earlier, this meant changing the policy for everybody, which may not be the intent at all.  This is especially true if there are both active and inactive users in the directory, since active users will not get the normal "your password is about to expire" warning X days before it's too late.  Reverting your password expiration policy setting back to the original value could result in a portion of your active users suddenly being locked out and calling for help.  In Windows 2008 and later, you can have multiple expiration policies within a domain, but your user objects may not be grouped to distinguish the inactive users of concern.  You could identify them and move them (and even script that step), but then you may have to move them back to many different OUs (Organizational Units) which could be just as much of a pain as the original problem.

Or you could follow this set of steps (which are scriptable!):

1. In Active Directory Users and Computers, locate the user with the expiring or expired password
2. Check the "force password change at next logon" box.
3. Click Apply.
4. Uncheck the "force password change at next logon" box.
5. Click Apply.

And VOILA!  That user's password expiration has just been snoozed-- effectively reset for another iteration, and with zero knowledge of the current password.  The password last set date will appear to be the moment you hit step 5.

How does this work?

Under the hood, the user attribute which stores the date/time when the password was last set is also dual purposed for the password must change flag.  The value is a really large integer which contains the number of ticks of seconds as a representation of time.  But when the force password change button is checked, the value of seconds of time is wiped out.  "Empty" is how the flag is stored.  The last date/time is wiped out.  So, when the administrator unchecks the force password change checkbox, AD Users & Computers has to put SOMETHING in that attribute, because NOTHING appears like it is flagged for change.  But the original value is gone forever!  So what does it store there?  The current date/time.  Hence, the user appears to have had its password reset without any actual (visible) changes to the user.

This can all be scripted out using the dsquery and dsmod commands the Microsoft ships with Active Directory.  PowerShell could also be used.  Or, an astute C# (or VB) .Net developer could simply take a look at the Securology GitHub repository, to see the example Password Snooze Button console app, to incorporate it into your organization's existing user management applications and services.

For the Auditor

To detect if an organization that you are auditing has been using the first option (administrative password resets to snooze the expiration), look for:

• Event log data for password resets of multiple accounts at roughly the same time, since this would likely be done "in mass" by the IT administrator
• Service accounts that all have roughly the same password last set date and time.  Manually resetting multiple passwords would have a period of time between each reset event, but a script would cause them all to be within a few seconds of each other
• User accounts that have been in existence for longer than the password expiration policy's time out, but that have one or few historical passwords stored in the directory (requires a very low level AD editing tool to discover), while still being active (lots of log on events)

To detect if an organization has been using the second option (password must change flag), look for:

• Lots of user accounts with nearly the same date/time value for the password last set attribute.
• Lots of user accounts that have not logged in since their password was last set.
• If event log data is available, look for lots events denoting the must change password flag was set or unset.

Even if long term historical event log data is available, the determined IT administrator could spread out these events to appear sporadic, random, or intentionally related to a user's call to a help desk.  A determined administrator could both keep the lights on and keep auditors at arms' length without detection of a policy violation.

Securology's Open Source Repository on GitHub

Securology now has open source code on GitHub!
https://github.com/Securology

This is something we have wanted to do for some time and finally are now able!  As our contributors find the time and freedom to contribute some of our intellectual property back to the greater community at large, we will add more repositories and content there.

Our first offering is a C# .NET wrapper that can do more to manage Microsoft Active Directory instances (including Active Directory Lightweight Directory Services, formerly known as ADAM, or Active Directory Application Mode) than any other open source project can do (which is why we wrote it in the first place).  Our open source Active Directory Services repo is available here:
https://github.com/Securology/ActiveDirectoryServices

In addition to shipping a core library that extends Microsoft's out-of-the-box functionality that ships with the .NET runtime (System.DirectoryServices.AccountManagement), we also have fully working example applications that are consumers of the library, so you can see how to use all of the features we have built.

Here's a list of just some of the features our consumer applications can do:

• Create, Edit, Update, and Delete Active Directory objects Users, Groups, Organizational Units (OUs), Contacts, etc.
• Create, Edit, Update, and Delete AD-LDS (ADAM) UserProxy and UserProxyFull objects.
• Sync AD Users into an AD-LDS (ADAM) instance as UserProxy or UserProxyFull objects.
• Create, Update, Delete, and generally manage/sync dynamic AD security/distribution groups based upon reporting relationships (if those are defined within Active Directory).
• Enable, set, and maintain Microsoft Exchange attributes to enable objects to become visible in the GAL (Global Address List), which also works for Microsoft's Exchange Online hosted service via DirSync.
• Import various rooms and resources from a .CSV file into Active Directory and enable their visibility in the Exchange GAL.
• Enable and Manage Office Communicator/Lync attributes to turn on/off access to your company's Lync/OCS server, setup default policies, including access to any internet-facing proxy servers as well as archive/logging per user.
• Generate random passwords for users.
• A nifty way of "snoozing" when a AD user's password expires while keeping the same password.
• And much more...

Eventually, we will share a working Provisioning Web Service that will be a great solution for limited budget organizations that want some of the functionality Microsoft's Identity Lifecycle Manager (ILM) includes, without the heftier license cost and infrastructure requirements.

More follow-up posts will follow.

Google Glass Privacy Issues Emerging

As the general availability of Google Glass draws nearer, more and more privacy issues will emerge.  He are some of the recent ones:

The glasseslike device, which allows users to access the Internet, take photos and film short snippets, has been pre-emptively banned by a Seattle bar. Large parts of Las Vegas will not welcome wearers. West Virginia legislators tried to make it illegal to use the gadget, known as Google Glass, while driving. 

“This is just the beginning,” said Timothy Toohey, a Los Angeles lawyer specializing in privacy issues. “Google Glass is going to cause quite a brawl.”

Read the rest at the NY Times.

The implications for such technology at casinos is very interesting.  What will happen when future versions of Google Glass become so small that casino security guards don't notice them?

Privacy Preserving Background Checks

We are going to attempt to address this issue without politics, with minimal bias (anyone who says they are unbiased is selling you a bill of goods), and with our creative problem solving hats on.

The problem?  Background checks.

The constraints?

• The checks must be run before a critical event (e.g. purchasing something dangerous, like a 32 ounce soda!)
• The checks must be available for private parties and individuals to use.
• The checks must be privacy preserving.

When we boil the core issues down, those who are astute in similar problems will note the similarities between this and electronic voting.  In e-voting, we must preserve the privacy of which choices were made on the electronic ballot, while at the same time proving that a voter's vote was indeed cast and counted.  It's not as simple as some people would make you think.  No, just because you can bank online and buy products and services online, does NOT mean that standard e-commerce security mechanisms will preserve this level of privacy.  This is different.  We've written about that before, so for a more deep dive read there first.

Given the timing and today's political culture in the U.S., this is obviously related to "universal background checks" for firearms purchases.  Our bent here at Securology is that firearms are neither good nor bad-- they are inanimate objects.  In the hands of lawful citizens, they are even better.  But we're not discussing that (just disclosing our bias).  We are not even talking about whether such background checks will stop crimes (we are convinced they won't deter but a very minor portion of dumb criminals-- and even for them it may only be a speed bump).  What we are discussing is the academic nature of this problem.  Given the desire for a backround check system, is a compromising solution even possible?  What might it look like?

Those in favor of firearms ownership without background checks are generally concerned that either criminals or organized criminals and government overthrowers may use "the list" of firearms and their owners for a door-to-door confiscation.  We will not be discussing that.  While we generally believe any such "list" is wrong and could lead to that, we also believe it is foolhardy for anyone on either side of that type of a conflict to take a side.  It leads only to pain and death-- a topic for another day, maybe.  However, we will assume this worst case to be a constraint: under no circumstances should our "system" (the one that we are thinking creatively about here) allow a "list" of firearms matched to their owners to exist.  At least not concretely and discretely (realizing there are a myriad of other data points that could build such a list, like credit card purchases, GPS waypoints from when a smart phone visits a gun range, CCW permits, and the list goes on ...).  

Shaking the politics off for a minute, it is an interesting academic problem.

On the private party constraint, a "system" like this must allow for two individuals with no prior knowledge of one another to prove that the buyer has been "cleared" to make the purchase (i.e. no prior felonies).  Likewise after the exchange, no clear indication of whether an actual transaction or just the precursor for a transaction should transpire.

Perhaps something like this:

1. Potential buyer makes request to the background check system.
2. The system verifies the buyer's non-felony status and returns a "number", an identifier that is valid for some period of time, say 14-30 days.
3. The buyer then takes that validation code to a seller, who can validate the code's authenticity in the system, matched up to the buyer's name.
4. The buyer and seller can then proceed to make a transaction and exchange of goods, or not.  Either way, the transaction was validated before.
5. As a legal requirement, the seller could be required to keep a copy of the validation code and buyer's name for some period of time, e.g. one year.  And to further assert that this data is used lawfully to preserve privacy, it could be a felony to intentionally divulge it to any third party, including law enforcement, without a warrant.

Entering any more "data" into a system to provide a full "chain of custody" would generate "the list" that is one of our constraints to specifically avoid.  However, many advocates of a "universal background check" system believe that at any time, a given item identified by its serial number, make, and model, should return a list of all of its owners and the duration for which they owned it, including the transfer of ownership date.  That "chain of custody" by default is the feared "list".  While we are not discussing the pros and cons if such a list existed, we state with confidence that no solution exists that can both create chain of custody and satisfy the constraint of privacy stated at the beginning of this thought exercise.  We may as well give up on that and move on to solving perpetual motion.

If the system we opined were to exist, there would most certainly be abuses of it that neither those in favor or against controlling possession of [widgets] (so tired of saying gun control when this could be applied to anything from household cleaners, to fertilizer, and now even to pressure cookers since the Boston Marathon).  For example, many organizations perform background checks on potential volunteers or employees prior to allowing them access to perform certain duties, and the checks they perform are typically accomplished through third party services which charge fees for the service.  Those service providers will most certainly be against a system like the one we are discussing in this article, simply because an organization could pretend to be a firearm seller and have their potential volunteer/employee pretend to be a firearm buyer.  What's good enough to pass the "background check" for the possession of firearms, is probably good enough to work in sensitive places like a hospital or a daycare.  Perhaps, then, if a system were implemented, it should be one-step abstracted away from the item that politicians are trying to control (widgets, er, firearms), and the political will of those in favor of such controls should be redirected more generally (and probably more beneficially) towards a generic background check system?

Or, as an anonymous person recently stated in the comments of an article on a similar topic: perhaps if society TRUSTS an individual to be free enough to walk around, drive a car, purchase alcohol, etc., then we should automatically determine that person has cleared any "background check" and needs no further interference prior to lawfully acquiring any widget of his choosing?  In other words, if they're too dangerous to own a firearm, drive a car, or have access to alcohol (listed in statistically more dangerous order), perhaps they should not have been released from prison?  If freedom is restored, let all freedom be restored.

Note: a similar solution to this problem has been presented by US Senator Coburn, though we are not aware of the specifics.

College Students Sneak Into Super Bowl

A pair of college students apparently sneaked into the Super Bowl while recording the whole social engineering event on video!

Breaking into Kaba Door Locks

This is an older issue that was resolved by an update from the manufacturer, but it's still an interesting story.

Continuing from yesterday, Marc Weber Tobias also was instrumental in getting Kaba to update their Simplex push-button mechanical combination locks.  On those door locks, which have seen near ubiquitous deployment, a mechanical combination is entered into a push-button key pad, which unlocks the door.  Some models include other features, like "bypass" which allows a person inside to egress through the door without pushing the combination.  It's this feature on the Kaba lock that Tobias learned could be defeated with a rare earth magnet.

Here's a (slightly dry) walk through of how the lock is defeated using just a magnet, leaving no forensic evidence of unauthorized entry whatsoever:


One aspect of this story that will be interesting for computer security professionals is the element of "responsible disclosure" used by Tobias to attempt to force the hand of the manufacturer to fix the problem, followed by the manufacturer's all too familiar "there is no such problem" response (yet they did fix it).

Breaking Physical Locks

Recently, Wired Magazine ran an article about just how easy it is for children to break into certain models of gun safes.  Their findings are interesting, but not totally surprising.  Watch for yourself if you haven't already seen it:


We did our own review of pistol safes here, but more or less comparing features of safes, not attempting to penetrate them as the article describes.

One of the researchers, Marc Weber Tobias, has a variety of other very interesting (but dry) videos describing physical lock security and some of the particular products that are defeated.  His YouTube channel is worth a review.

Achtung! Inauguration!

Here is an interesting first person account of the security at the President's recent gulag inauguration:

In theory, Barack Obama’s second inauguration was a public event, taking place outdoors at the United States Capitol, with giant screens sharing the broadcast along the National Mall. In practice, access was limited to those willing to surrender their dignity and personal rights in order to pass into a giant swath of Washington, DC that was taken over by police, the military, and various government agencies.

Read the rest (and look at more amazing photos).

Argus: Big Brother in the Sky

We live in interesting times:

Ban Hammers

Did you know the FBI statistics indicate that for every year since the 1994-2004 Assault Weapon Ban sunset into history, more murders are committed by hammers and clubs than with a rifle (and "assault weapons" at best is a subset of "rifle")?

An excerpt from Breitbart:

[L]ooking at the FBI numbers from 2005 to 2011, the number of murders by hammers and clubs consistently exceeds the number of murders committed with a rifle. 

Think about it: In 2005, the number of murders committed with a rifle was 445, while the number of murders committed with hammers and clubs was 605. In 2006, the number of murders committed with a rifle was 438, while the number of murders committed with hammers and clubs was 618. 

And so the list goes, with the actual numbers changing somewhat from year to year, yet the fact that more people are killed with blunt objects each year remains constant.
For example, in 2011, there was 323 murders committed with a rifle but 496 murders committed with hammers and clubs.

To quote Schneier on rare risks (written, ironically, in the context of the aftermath of the Virginia Tech homocides):

Novelty plus dread equals overreaction.

We can see the effects of this all the time. We fear being murdered, kidnapped, raped and assaulted by strangers, when it's far more likely that the perpetrator of such offenses is a relative or a friend. We worry about airplane crashes and rampaging shooters instead of automobile crashes and domestic violence -- both far more common.

In the United States, dogs, snakes, bees and pigs each kill more people per year than sharks. In fact, dogs kill more humans than any animal except for other humans. Sharks are more dangerous than dogs, yes, but we're far more likely to encounter dogs than sharks.

Our greatest recent overreaction to a rare event was our response to the terrorist attacks of 9/11. I remember then-Attorney General John Ashcroft giving a speech in Minnesota -- where I live -- in 2003, and claiming that the fact there were no new terrorist attacks since 9/11 was proof that his policies were working. I thought: "There were no terrorist attacks in the two years preceding 9/11, and you didn't have any policies. What does that prove?"

What it proves is that terrorist attacks are very rare, and maybe our reaction wasn't worth the enormous expense, loss of liberty, attacks on our Constitution and damage to our credibility on the world stage.

We need to have the courage to not overreact.

Zombie Free Zones

We do not have the original source/attribution for this.  Whoever you are ... GENIUS!

Did Autozone make the right response?

Recently, Devin McLean, an Autozone retail store employee, exited his Autozone store, went out to his vehicle to retrieve a handgun, and re-entered the building after he noticed the locally infamous "fake beard bandit" enter the store and pull a gun on a coworker.

Autozone fired McLean, citing a "zero tolerance" corporate weapons policy.

Is Autozone safer as a result of this policy?  We don't think so.  Future robbers will know that employees have to put their paychecks on the line to stop a robbery.  Why bother pulling your own gun as an employee when it's most likely your employer's money the robbers want anyway?

Is the business better off?  Boycotts of the retailer are already mounting up.  Though there may only be a slight dip in the company's revenue, some money was still lost.  The question most likely on Autozone's upper management is a cost/benefit analysis of the lost boycott revenue vs. lawsuit liability in future cases that are not so cut and dry as McLean's.  In other words, their current decision suggests their paranoid corporate lawyers have more influence than any calls to black/white morality in the moment.

Did they make the correct choice?  You decide.  Sound off in comments below.

11 Ways a Condom Can Save Your Life

Um, file this under "survival".

How to Spot a Hidden Handgun

Not new, but worth reviewing, from excellent infographic artist Megan Jaegerman.  This is by no means an exhaustive list of "tells" for concealing a firearm (we can think of a few we may have to write about another day).

How to spot a hidden handgun (click to view full size):
 

Achieving Flight via AK47

There's a funny over at XKCD, pontificating if flight is possible given the recoil of AK47s.  Theoretically, it just might be so.  Here's an excerpt:

"Is it possible to build a jetpack using downward firing machine guns?”  

—Rob B

I was sort of surprised to find that the answer was yes! But to really do it right, you’ll want to talk to the Russians.

The principle here is pretty simple. If you fire a bullet forward, the recoil pushes you back. So if you fire downward, the recoil should push you up.

The first question we have to answer is “can a gun even lift its own weight?” If a machine gun weighs ten pounds but only produces eight pounds of recoil when firing, it won’t be able to lift itself off the ground, let alone lift itself plus a person.

In the engineering world, the ratio between a craft’s thrust and the weight is called, appropriately, thrust-to-weight ratio. If it’s less than 1, the vehicle can’t lift off. The Saturn V had a takeoff thrust-to-weight ratio of about 1.5.

Petraeus: Know Thy Enemy

In a bit of wisdom harkening back to the days the Art of War, Computer Science professor and security expert Matt Blaze has sage advice to anyone wishing to follow former General Petraeus' steps:

“Understanding the threat is always the most difficult part of security technology,” said Matthew Blaze, an associate professor of computer and information science at the University of Pennsylvania and a security and cryptography specialist. “If they believed the threat to be a government with the ability to get their login records from a service provider, not just their spouse, they might have acted differently.”