I'm working on getting a paper submitted to a Journal, and I discovered that Bibtex and Zotero disagree about how to express URLs. Zotero is one of my favorite tools, but it doesn't always escape special characters in its URL field when exporting to Bibtex format. It does a pretty good job on other fields, but drops the ball on URLs. This gives puzzling errors and causes big issues for users of Lyx (another great tool).
Rather than fix these by hand, I wrote a python script to parse the file and automatically escape the character Bibtex was choking on. I hard coded the file names, and it's not a nice utility, but I'm releasing it under the GPL and the CRAPL in case some one else needs it in a bind.
The tool is hosted here.
It reads a file "lib.bib" as input and outputs an escaped version as "out.bib"
If this helps you, or if you have an addition, leave a comment!
Thursday, October 14, 2010
Wednesday, September 29, 2010
Map locations as passwords
Word is out on Bill Cheswick's idea for online authentication that is based on using a highly specific location on a map as one's "password." It's a neat idea, and something better than remembering passwords would be fantastic. I don't think this is the breakthrough we need, though. To abuse a Churchill quote, passwords are the worst authentication method -- except for all the others we have tried.
The idea is interesting -- use a a pair of 10-digit latitude and longitude coordinates to comprise a 20 digit password. Instead of a user remembering 20 digits, he remembers "that blue house outside of town." When prompted for authentication, he moves the mouse to that location and clicks it. This will obviously defeat keyloggers, and mouse monitors can be fooled by initializing the map in a new place each time.
Others in the online discussion have pointed out flaws. One of these is that shoulder surfing is once again a threat to password security. Another is that users will tend to choose familiar locations like their homes or prominent landmarks. Yet another is the possibility of analyzing cached map images to determine the sensitive location.
Another problem is that I believe it easier to remember several phrases than several places. This will make it more tempting to use one or two locations as the shared secret, and a compromise of one account will compromise another.
They haven't done any usability studies on this yet, but I think a problem that will emerge is that the precision necessary for clicking the correct location will be a big issue -- especially with older or highly-caffeinated users. One obvious fix is to allow a range of error from the actual spot; however, this will complicate secure password storage. The standard method of storing only a hashed password (with or without salt) is not an option if a range of passwords must be accepted.
This idea was presented at NYIT's Cyber Security Conference earlier this month. In the speaker's bio, he says that in the talk he'd present several half-baked ideas. I think this work isn't the solution, but we need more half-baked ideas for the problem.
Slashdot picked up on this, as did Discovery and Tech News Daily.
The idea is interesting -- use a a pair of 10-digit latitude and longitude coordinates to comprise a 20 digit password. Instead of a user remembering 20 digits, he remembers "that blue house outside of town." When prompted for authentication, he moves the mouse to that location and clicks it. This will obviously defeat keyloggers, and mouse monitors can be fooled by initializing the map in a new place each time.
Others in the online discussion have pointed out flaws. One of these is that shoulder surfing is once again a threat to password security. Another is that users will tend to choose familiar locations like their homes or prominent landmarks. Yet another is the possibility of analyzing cached map images to determine the sensitive location.
Another problem is that I believe it easier to remember several phrases than several places. This will make it more tempting to use one or two locations as the shared secret, and a compromise of one account will compromise another.
They haven't done any usability studies on this yet, but I think a problem that will emerge is that the precision necessary for clicking the correct location will be a big issue -- especially with older or highly-caffeinated users. One obvious fix is to allow a range of error from the actual spot; however, this will complicate secure password storage. The standard method of storing only a hashed password (with or without salt) is not an option if a range of passwords must be accepted.
This idea was presented at NYIT's Cyber Security Conference earlier this month. In the speaker's bio, he says that in the talk he'd present several half-baked ideas. I think this work isn't the solution, but we need more half-baked ideas for the problem.
Slashdot picked up on this, as did Discovery and Tech News Daily.
Tuesday, June 29, 2010
Setting up OpenVPN using Network Manager in Ubuntu 10.4
Hi, everybody!
I spent the last little hour or two trying to get a VPN working back to my department's network. The IT guys make this a snap for their Windows users, but they haven't gotten around to unsupported operating systems.
This guide is getting OpenVPN working using the Network Manager GUI using Ubuntu 10.4; this guide in particular covers the "Password with certificates" option, because that's what we use.
I wanted to use the GUI that should "Just Work" in Ubuntu. The Ubuntu Documentation is a little old, so I thought a complete write up would help somebody else in a similar situation. Additionally, a number of the problems I came across hadn't been really addressed properly in a clear way in the forums. I've had to relearn this twice now, so I should probably write it down.
Part 1: Basic Setup
Step 1: Acquire Certificates
You'll need the certificates from your OpenVPN server. You'll also need the URL or IP address of your VPN gateway (i.e. server). Your sysadmin can probably help you with this.*
Step 2: Install packages
You'll need to make sure you have all of the right VPN packages, because they don't come by default. Use this command from your favorite terminal:
sudo apt-get install openvpn openssl network-manager-openvpn
Part 2: Use the Wizard
1. Click on the Network Manager Menu on the panel, slide down to 'VPN Connections>' and click 'Configure VPN'
2. In the 'Network Connections' dialog that appears, click 'Add'
3. In the 'Choose VPN Connection Type' dialog that appears, choose 'OpenVPN' and press 'Create'. This opens the 'Editing VPN Connection' dialog in the VPN tab.
4. Under 'Connection Name', give a name of your choosing.
5. You can click the 'Connect Automatically' check box if you like.
6. In the 'Gateway' field, give the domain name or IP address of the VPN server that you got from your network admin. For MSU ECE'ers, this is vpn02.ece.msstate.edu .
7. In type, choose "Password with certificates." If your network uses a different strategy (certs only, etc.) change this here.
8. Give your username and password for your network in the fields provided. You may opt to leave the password blank here -- it will prompt you when you try to connect.
8. For each of the 3 certificate types, give the file name on your system where you placed it. (I have a 'crypto' folder in my home directory where I keep VPN certs as well as GPG and SSH keys). Your private key may or may not have a password associated with it. (I didn't).
9. Click 'Advanced.' If you know that your VPN server uses a custom port, specify it here. Mine used the common 1194. Also, if your VPN uses compression, check the box (mine used LZO). Some VPNs use TCP, but the default is UDP. If yours is TCP, check that box (mine was not). Also, it's likely that your VPN uses a 'Tap' structure; if this is the case, as it was in mine, check that box.
10. Open the IPv4 tab in the 'Editing VPN Connection' dialog.
11. Under method, choose 'Automatic (VPN) addresses only'
12. Click the 'Routes' button, and check 'Use this connection only for resources on its network'. This step makes it possible to use both your machine's local internet and VPN.
10. After those steps are done, restart network manager. I wasn't sure the easy way to do that, so I just rebooted my system.
11. After restart, click the network manager and scroll down to 'VPN Connections.' The new connection you created should be there -- Click it to connect. It should work now!
Hope this helps someone. If you have questions/suggestions, leave them in the comments!
*For fellow MSU ECE'ers, you can get them here if you are on the campus network.
Subscribe to:
Posts (Atom)