Linux Means Business: Security and Authentication with Digital Signatures
This system has a couple of weaknesses. For one thing, it offers only file-level protection. It checks all the logical possibilities of modified files, deleted files and extra files. What about someone modifying the disk in some strange way that fools the upper level routines? Digitally signing a representation of the raw disk data is more secure.
This system is also vulnerable if the public key on the server could be modified or replaced with a different one. The same vulnerability exists for the upgrade software on the server. In practice, getting root access in order to replace the public key and creating unauthorized upgrades is a roundabout way to launch an attack. If the attacker already had root access on a particular computer, there wouldn't be any reason to use the upgrade system to get privileges or modify the server.
With the labs gradually coming on-line, we're dealing with the problem of authenticating student access. Most schools can just put a login program on their client PCs which checks the user's password against a central database via a high-speed campus LAN. This won't work for us for many reasons. Many of our labs will not be on-line in the near future. Even when on-line, the network support is unreliable and often slow. Another problem is that we have lots of weekend seminars students sign up for at the last minute. The students sign up for classes in small “education centers” that send us floppy disks with registration information via snail-mail long after the fact. Even if every lab were on-line, the logistics of collecting and distributing all of the information overnight would be extremely difficult. Luckily, public key cryptography and clear-signed digital signatures offer a solution:
A public and private key pair are generated for use by Field Representatives (FRs).
The FR public key is stored on the computer lab servers.
At registration time, a student entitled to computer lab access brings a floppy disk to the FR.
The FR clear-signs a certificate with the student's name, ID number, dates of validity and, optionally, information about which privileges are granted.
At least five characters are removed from the digital signature block and given to the student as his “password”. In Listing 3, the last five characters of the second encrypted line were used as the password.
The first time a student uses any particular computer lab, he inserts the disk into a client PC and enters his student ID number and password. The password and certificate on the disk are recombined and sent to the server where it is checked using the FR's public key. If the signature is both valid and unexpired (based on the dates in the certificate), access is granted.
One final step makes the system more convenient for students when returning to a lab. The server maintains a simple database, keyed on the student ID number with the student's password encrypted with a standard one-way encryption routine like crypt(1). The next time a student visits that particular lab, he doesn't need to bring the floppy disk; he can just enter his password and be validated.
This database is automatically managed in the same way as a DNS cache. The date of expiration from the user's certificate becomes a “time to live” field in their database record. A cron job can be set up to periodically delete all expired entries.
This scheme has a lot of advantages. Reliable communication between the field staff, the main office and the labs is not required. Each of the three can be in completely separate, isolated locations. (And this is often the case.)
As in the first system, no real “secrets” are stored on the lab servers. If someone gets access to a lab server, there's no information that can help him: the public key can be read by anyone. The encrypted passwords are stored on the server; however, since they're random strings and not picked by the users, they aren't susceptible to the typical dictionary attack. Apart from dictionary attacks, standard Unix passwords are usually a secure system.
Various user access levels and periods of validity can be assigned to students by adding them to the certificates. The certificate can contain more information than just the student's name and ID number. Any kind of information that's worth keeping track of can be put into it.
Students have instant access to the computer lab once they've received their certificate. There is no delay waiting for a database to be propagated.
Since the certificates are in plain text, students can see at a glance if the certificates are correct, if they've expired yet, etc. This should make the system user-friendlier, and also limit the amount of assistance needed for help desk calls. There would never be any question about whether a certificate was still valid, issued for the correct person or contained the correct information.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- RSS Feeds
- Senior Perl Developer
- Technical Support Rep
- Non-Linux FOSS: libnotify, OS X Style
- UX Designer
- Reply to comment | Linux Journal
2 min 31 sec ago
- Android has been dominating
7 min 3 sec ago
- It is quiet helping
2 hours 52 min ago
3 hours 9 min ago
- Reachli - Amplifying your
4 hours 26 min ago
5 hours 15 min ago
- good point!
5 hours 17 min ago
- Varnish works!
5 hours 27 min ago
- Reply to comment | Linux Journal
5 hours 56 min ago
- Reply to comment | Linux Journal
8 hours 22 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?