What we need is something to handle HTTP requests. Thankfully Flask does this for us and is extremely easy to use!
First thing we’ll do is import all of the stuff we need/want:
from flask import Flask, request, redirect, make_response from twilio import twiml as TwiML, TwilioRestException from twilio.rest import TwilioRestClient from db import * from peewee import SelectQuery
This imports the important Flask and Twilio options as well as our database reference. 🙂 Now we need to initialize Flask before we get too happy:
app = Flask(__name__)
In a way you can think of this as like using logging.Logger(), you typically pass it __name__ so that it has a reference.
Now, lets make it so when we go to http://ip_address:5000/ we see a message:
@app.route("/", methods=['GET', 'POST']) def main(): return "You sure?!"
The method name is irrelevant (though has to be unique per route). The “/” is the same as when visiting http://ip_address:5000/, and we will let the main handler support both GET and POST requests. Now, when you visit the URL you’ll receive “You sure?!” in your browser.
After, we need this two-liner:
if __name__ == "__main__": app.run(host='192.168.0.102', debug=True)
However, change the IP in host to one that is reachable from the Internet (or set up port forwarding) so later on Twilio will be able to connect to the web service. Now, open up your browser once you run the script and you should see the message. 😀
This was short but, then again, there’s not a whole lot that needed to be covered to get Flask up and running by itself. Next, however, will be when the fun starts and we work with Twilio’s helper library.
Lets figure out what we need to make this magical wonderland happen. We need a user’s phone number, a field to state if the phone is usable or not (if we should concern ourselves with requests from it) and storage for the active token. If we want to make it more advanced than we will but for now this is good. So we will use two tables: phone and tokens. The token will be based on the phone number and current timestamp as sort of a salt (not the safest but again, template for the future 😉 ).
id – primary key
digits – small integer (15-digit number)
id – primary key
token – variable char (length 0f 10)
phone_id – foreign key to phone->id
Simple, eh? Now lets create it in Python!
from peewee import *
database = SqliteDatabase(“2fa.db”)
We import everything of the Peewee library to make things easier on us. We also specify we want a SQLite database.
database = database
We create an abstract base class (ABC) so everything can share the database instance. This is mostly done to save typing.
id = PrimaryKeyField()
digits = IntegerField()
id = PrimaryKeyField()
token = CharField(max_length=10)
phone = ForeignKeyField(Phone)
Specify the table structure of the phone and tokens tables, subclassing the mentioned ABC class.
phone = Phone
tokens = Tokens
Easy references for the tables (which will be needed quite a bit).
Connect/load the SQLite database.
Create the tables in the SQLite file.
Save the above code fragments to a file called “db.py” (otherwise make the adjustments in later parts). Now we have the database laid out properly and easy to work with!
For the point of this guide we are going to be using just our test account number. The only difference between that and a purchased number is that every SMS or call is prefixed with a “Thank you for using Twilio” kind of message. For demo’ing everything its a small price to pay. I’ll also be walking through this with you as well by creating a new account.
- Sign up for Twilio here: https://www.twilio.com/try-twilio and enter the appropriate information.
- It’ll prompt you for a phone number so they can verify who you are (i.e.: a bot wasn’t programmed just to sign up for the service), enter your phone number. I used Google Voice and had no issues. You’ll receive a text message with a verification code. Enter that.
- Twilio will generate a phone number for you, you can either use the one provided or search their database for a specific number.
- Once you pick a number it’ll let you test some of its basic features. Its helpful to make sure everything works fine at least. 🙂
- Click on “Go To Your Account” and you’ll be presented with a pretty nicely done dashboard
In the dashboard make a note of your account SID and auth token (hover over the little padlock icon and click it to make it visible). You’ll need these later, SID being your account ID and the token being the SID’s password (so keep it a secret!). There’s a lot of useful information Twilio gives you and its awesome. But, lets continue on. You don’t need to do anything else in the dashboard yet. Now we’ll get started on our web service so we can make magic happen!
Just like everything else with IT security, once a gem is found everyone jumps on it. Originally I was going to offer this as a service for my business (still might to a degree), but instead thought I’d share with the Internet how to create yourself a beneficial two-factor authentication system. In the end, you’ll be able to validate authentication requests either via SMS or voice and be proud of the extra power!
While there’s few requirements for this, they should still be addressed:
- SMS & Voice Provider: Twilio
They have been around for a while and give you $20 worth of credit to use for your test number when you sign up. This should be far more than enough for your use as 1 SMS = 0.75 cents and 1 outbound call = 1 cent. While it does cost to also have a number ($1/month/number) its still a valuable service in a small market. Also note that pricing is relative to when I wrote this.
- Language: Python
I am not a pro at Python but it is the easiest I have ever worked with thus far. It also is easier to deploy on various systems.
- Help Libraries: Flask, Peewee and Twilio
Flask is used to process web requests (i.e.: make our Python script act like a minified web server) and Twilio has a Python client/module/helper library that helps us tie very easily into Twilio’s REST API. Peewee makes database connections and such A LOT easier. I won’t go into the mechanics of it but basically its an ORM (object-relational mapper).
- Database: SQLite
Any database will do and I’ll just be covering the table layout here (fields, types, etc…). I’ve since used PostgreSQL after I stopped writing this code and if I did it again I would choose PostgreSQL in a heartbeat. But for a starter guide SQLite is great. After all there’s not a lot of fancy work that needs to be done here.
A sort of pain the butt aspect of Twilio, however, is that numbers have to be in E.164 format. Essentially what this means is that any numbers (even your own Twilio one) that are passed through the Twilio client must be in the format of “+[country code][area code][rest of digits]” so if your Twilio number is 1.234.567.8900 then when you use the API it’d be +12345678900. While its not a big deal it can be annoying to work with at first.
I don’t suggest using the code as is for public use. This was intended for such but back then I was still in the infancy stage. However, this code can be used to build your own as I intend on those who are reading it to take what’s given and run with it at the end.
This guide assumes you have all the mentioned required stuff installed and ready to go.
Twilio does have a tutorial and code for creating a two-factor authentication system using their backend. The major difference between my code and theirs, however, in terms of purpose anyways is that mine generates a random token that has to be entered. You’ll see more of what I’m talking about when we get deeper into everything. The next part will cover setting up Twilio for use.
A recent article on Slashdot discussed the aspect of Google requesting to start using dotless TLDs. While ultimately ICANN denied this request, its interesting to see where the future of the Internet very well could go.
Most filter systems use wildcards but not to a scalable extent (in such a way that future concerns are taken care of as well). It does make sense in some aspects, though. How is anyone to know that dotless domains will ever happen, for example. Another issue is that filtering through a long list of futuristic ideas still adds more overhead to each request, which even when cached can pose some annoyances.
Should filtering be done on a whim, when new techniques/resources are made available or when its best suited for the network? Its tough to say.
When building a LAN you could easily tell the filtering system to deny any requests to *.onion, but then you have to consider how likely it’d be to even set up a Tor node within the network, have it connect successfully and allow applications like web servers. If all of these are also possible then you have more concerns than just filtering which domains are accessible.
TrueCrypt is a very popular option for encrypting data, while dm-crypt+LUKS (LUKS is a module for dm-crypt) is an unsung hero of sorts for those who don’t want to install a lot of software.
- TrueCrypt allows encrypting an entire hard disk, while I haven’t found a way for dm-crypt to do this
- Both allow you to create containers to store data
- Neither allow expendable containers (unless TC has changed that)
- Process of creating a container in dm-crypt is more troublesome than with TC
- TC allows for more encryption options out of the box, while dm-crypt may allow more with additional effort
- dm-crypt does not require administrative rights (except for probably mounting)
There will always be people who make a mountain out of an ant hill. However, it hits me in a sore spot when people like to make a simple issue seem like Armageddon.
The Register posted an article about an ISP monitoring mouse traffic on their support pages. The headline of it makes it seem like they’re monitoring all traffic going through their wires, while when you read the article itself its just about them monitoring mouse clicks and activities on their support pages. Why should this be considered a security threat?
I’m not aware of The Register’s credibility but this has greatly hurt it for me personally.
While I can see some uproar about it simply because the end-user’s activities are being monitored, its not as if they are logging key strokes and sending them to the NSA (oh, wait…). They’re seeing what pages are being read, what bounce and exits are being done, etc… Hell, Google Analytics does this for you for free. Its becoming just a little too much for me to handle at the moment with everyone crying wolf without even knowing what sheep look like.
“Being compliant” is a big buzz word as of late that really adds nothing to the company needing it. Chances are people will be able to tell you how they can make you compliant, but not be able to tell you why you should be. Granted, the flip side is that if you’re looking into compliance you should know why you want it done anyways, but still.
PCI and HIPAA compliance are probably some of the most common ones, both serving the purpose of credit card processing and medical records respectively. The main case for these is that more and more people are using plastic instead of paper to pay for things, and if you’re doing business online its virtually a necessity somewhere down the line. HIPAA, while part of me feels has seen its days as less and less people can afford to go to the doctors/medical professionals still holds a strong place in the government regulations (PCI isn’t governmental regulated).
I don’t know the fundamentals of HIPAA regulations (never really was concerned with it) but PCI is a tricky little fella. It has 4 classes/levels: A, B, C, D, which range from strictest – laziest. Most online merchants will fall between C & D and physical merchants will be A & B (simply due to the vast differences in how cards are handled). D, which is common for stores that are on shared hosting plans and do not actually store CC information is also the most common. A has the hardest checklist of items to pass, however. It goes not only into virtual security but also to physical as well.
While this won’t fit the mold for every SMB (small and medium business) out there, it will still give others an idea of what should be considered. This will assume the SMB wants to expand in the future.
Most SMBs do not want to stay in that classification forever. If the company knows their end goal in this regard early they should also be able to plan into the future in terms of software use like security applications (AV, IDS/IPS, etc…). Should you be expecting your company to go beyond the 5-50 employee mark (or however you deem a SMB) then knowing that the software is able to handle both a small, as well as enterprise business should be part of the concern.
2. Ease of Use
Software should be easy to use from the time you look at the pretty packaging or install file until its time to uninstall it for good. This is one area where a lot of vendors make their critical mistake, however.
If you need to write documentation on how to do everything then you’re doing something wrong. Documentation should be there for clarification, not how to use the software itself.
3. Easy Authentication
Typically there’s going to be some level of authentication whether directly (program requiring username and password) or indirectly (logging into the system to use). If the program does require the use of its own login system it usually makes more sense to tie it into the system itself as well. SSH is a prime example of this. It prompts the user for the username and password (or whatnot), but authenticates the user based on the system itself.
4. Automated Updates
No one likes having to remember to update anything, especially when its supposed to be set it and forget it. Automatically updating a program can pose issues in itself, however, most people don’t consider it until its too late. The convienence of not having to remember to hit the update button or run the script makes their life much easier, which is what you want the end result to be.
At this year’s USENIX talks, an interesting presentation was given describing how two people reversed engineered Dropbox’s client. This project, performed by Dhiru Kholia of Openwall and Przemyslaw Wegrzyn of CodePainters, showed how to both intercept SSL traffic (thus being able to manipulate the API calls) as well as bypass two-factor authentication. The authors also note, however, that for this attack to be efficient you need to already have compromised the machine:
Kholia concurred that hijacking a Dropbox client first requires hacking an existing vulnerability on the target user’s machine, which can be executed remotely.
So if you’re wanting to peak at your friend’s Dropbox account, you’ll have to dig deeper into the architecture to even attempt it. In the end they still proclaim Dropbox is a viable and efficient tool for its purpose, and were looking to open up the eyes of the IT security community and not devalue the usefulness of Dropbox.
From what I’m able to gather being able to intercept the SSL traffic opens up the flood gates of possibilities. You’ll be able to both see the data before encryption and after decryption and snoop out details you want/need.