is that the Patriot Act is probably not being misused... but I'm glad multiple organizations, including an arm of the D.O.J., are investigating all alleged abuses.
In September 2001, I wondered whether the C.I.A., or perhaps some renegade arm of the U.S. Army/Navy/Air Force, had instigated the attacks in order to immediately double their top-secret budget. Naah... no American would ever do something like that, right?
Then again, as far as I know, all the executives at Enron were U.S. citizens, and so were the officers who performed the notorious interrogations at Abu Ghraib. In the 1980s, the U.S. government secretly sold arms all over the world to renegade governments and rebels who were thought to be preventing the spread of Communism. Who knows what really goes on in government departments before the papers are shredded and the tapes erased?
Why carry it? Just install a flatscreen monitor and waterproof keyboard, and a wall-mounted box running VNC or something. In fact, if you just want to read the news, all you need is a web browser.
And the debit cards. The advertising on them is insane. They have some celebrity come out and get asked for ID then say - "With our Check Card, you Never need ID" And how is this supposed to be a good thing? I'm supposed to be happy that it is even easier for someone who has stolen a card to go and clear out my checking account?
I wonder if Visa is doing things like this to make the merchants happy -- after all, those are their actual customers (although consumers are the banks' customers, which may be why no bank wants to issue these cards.) Consider how checkout with a credit card is supposed to work now:
Comsumer approaches checkout with one or more items;
Cashier scans them;
Cashier states total;
Consumer hands card to cashier (who scans it), or scans it himself;
There may be a wait of a few seconds while the transaction is approved;
A sales slip is printed, and consumer signs it; OR an electronic screen is presented, which consumer is suppposed to sign;
(Apparently, only if the purchase amount is over some minimum) Cashier verifies that the signatures match;
If card says "see ID", Cashier requests ID;
Consumer presents ID, which cashier verifies;
Cashier hands card(s) back to customer, with reciept; customer mak now walk out with the goods.
I think Visa wants merchants to think about how they could make the process less labour-intensive; for instance, this could be combined with RFID on items as follows:
Customer picks up goods;
Customer walks out of store;
Profit!!!
(Customer recieves a charge on a random one of her several wireless-chip-based cards; that is her only reciept.)
This might be especially popular for souvenir shops at special events; I recently worked on the cleaning-crew for one, and they were doing several things to maximize customer flow, like putting the entrance and exit at opposite sides of the store, and pricing everything in whole dollars with sales tax included (to the sales personnel wouldn't have to make change). A bar might use this system to collect their cover-charge, too. As for myself, I stay away from such places.
LDAP is really just a database-access protocol,
with security and distributed-system features
built in. I believe RFC 3377 is the most recent
relevant standard.
Most LDAP directories are used to keep track of people;
therefore there is an InternetOrgPerson type which
(if I remember rightly) has the following attributes
by default:
CommonName (i.e., userID)
Full name
Password (can be stored with both Windows and Unix encryption,
or in plaintext)
Telephone number(s)
Mailing address(es)
JPEG photo
e-mail address
user ID #
home directory (?), shell (?) (these might be in some other type)
However, LDAP types are extensible, so you could
create a new type to represent employees, inventory,
or even projects, or you could extend an existing
type. For instance, you might want to add some of
the following to InternetOrgPerson (if they're not
already there):
GPG public key
instant-messaging ID
ID badge number
It's even possible to use an SQL or legacy-system
database as a backend for OpenLDAP with some custom
coding, although I'm sure a lot of people who use
it don't bother.
So that's what's in the directory. You might still
ask, "what is it used for?"
Firstly, Windows, Netware, Solaris and Linux can all be told
to get their login information from an LDAP directory.
This means that (if it works) someone only needs
one account in an organization, that their Windows
password is automatically the same as their Unix
password, etc. It does not mean that they need to
use the same home directory on all systems; but
home directories can be automatically created by
login scripts. NIS+ was a Unix-only way to distribute
just the information found in/etc/passwd; LDAP
is cross-platform.
Secondly, some E-mail clients (specifically
Netscape, its derivatives, and Outlook; I don't
have experience to speak for others) can treat an
LDAP directory as an extension of the address-book.
That sure beats running down the hall and referring
to a printed list every time you want to e-mail
someone or call them on the phone and only remember
their name.
Of course, if your "organization" is one person
working on ten computers in a family-member's basement, LDAP probably
isn't worth the effort.
I think you can still use routine logs as evidence. It helps if your AUPs or the login banner says something like "all connections are logged"; then you can at least say in court that "so-and-so tried to connect on such-and-such a date". If you're an ISP under a DOS attack, you are obviously a party to the communication; but you aren't expected to read the e-mail that comes through to decide whether your customers are cheating on their spouses.
First of all, I've measured power consumption of desktop systems with an ammmeter. A power supply may be rated for 500W, but only draw 120W, especially if the hard-drive spins down. A real "X terminal" could be something like the Sun Ray, which has no noving parts at all (fan, hard drive,...) and thus saves a lot of power.
Secondly, a regular desktop computer that's always-on can provide resources (CPU, disk space,...) to the network, so it isn't such a loss to leave it on.
Finally, Unix window managers (starting with CDE, which is about 14 years old) support "saving a session". This means I can log off one computer, walk down the hall, log in on another, and get my terminal windows and (some) applications back in the exact same place where they were before. If that's not good enough, you can use VNC to save your application-windows on a virtual desktop exactly where you want them.
Certain character ranges don't make sense in domain names (such as u2460-u24FF, "Enclosed Alphanumerics, and uFF01-uFF5A, the Latin part of "Halfwidth and Fullwidth Forms"). If the name uses characters from this range, WARN THE USER.
Characters are generally distinguisable from each other within a single script (Latin, Cyrillic, Hebrew, Arabic, etc.) If the domain name mixes alphabetic characters from different alphabets, WARN THE USER.
Note that {u0440 u0430 u0443 u0440 u0430} spells "paypa", but there's no Cyrillic letter that really looks like an "l" when printed.
Otherwise, it's probably safe not to warn the user. Furthermore, when a user goes back to a site he's chosen to visit befor, he needn't be warned again (so this could be like a cookie-blocker, etc.).
However, it would also help if the domain registries weeded out garbage domain-names, and if owners of high-profile domain names exercised due diligence in looking for attempts to get a domain that looked like their own trademark in a typical Unicode font. This isn't just a browser issue.
Yes, if you read the article, you see that AOL is *recommending* third-party news providers, such as Google Groups. I'm not sure whether they ever allowed an AOL users with a third-party news client to connect to their news servers.
Several of my family-members share an AOL dial-in account and use AOL primary email addresses. I don't know if they've ever read or posted to Usenet. Since I don't subscribe to AOL, I'm not sure if I have a say in the matter. I'm not happy about this, but I can understand whay I might drop Usenet too if I were AOL.
I'll aggree that 98% of the newsgroups are 98% spam, and the 2% that aren't (such as comp.lang.c) are 80% or more flame-wars and other garbage.
Furthermore, participating in Usenet with an unmasked email address is an invitation to recieve a lot of unsolicited e-mail. AOL has been fighting spam for some time.
Finally, Usenet (like IRC) is a sort-of peer-to-peer model that doesn't really fit in the modern Internet. Soemone can publish something by putting it on their website. For many people, e-mail will get to its recipient in under a minute; why deal with the propogation delays of hours or more that Usenet offers? RSS feeds, IM, true peer-to-peer clients, cheap or free personal websites, slashcode/PHPbb, listman... each of these is a better solution to some part of what Usenet used to be used for.
Nevertheless, I won't say Usenet is permanently dead. There are other sites besides groups.google.com that provide access to Usenet postings. There is promise in the other direction too. For istance, I might actually fire up an old newsreader like trn if I knew that Slashdot was putting its site on Usenet.
I don't think this is really going to cause much cash expenditure as such -- it's more of a "now you can't blame us" memo. Of course, an air-traffic controller's time is probably worth something, and so is the time of the police-officer who ends up reading the report, but police follow up low-priority incidents all the time. Besides, the person responsible for the government spending said cash is the yahoo who tries to shine a high-powered laser at an airplane. What would you do if you were driving down an interstate highway and someone shined a laser at you from an overpass?
Seriously, once in a while I draw diagrams of things like this in my spare time, but having five or ten different services running the entire length of a 700-mile corridor does sound like colossal boondoggle. It also sounds like an invitation to terrorist attack.
A 4,000-mile road would have to cover a longer path; say from the Hudson Bay to Acapulco, going through Mexico City, Houston, Chicago and Milwaukee on the way.
When I took an OpenGL programming class two years ago, people were still calling the room "the SGI lab" and the monitors might have originally been hooked up to Indy workstations; however, the computers actually in there were dual-Pentium boxes running Windows 2k Workstation with some version of Visual C++. As a result, I've never written an OpenGL program that didn't require MFC (which is a shame, because I otherwise do new development on Linux and XFree86 has good OpenGL support these days).
There are a lot of factors that one can consider in an argument about "how long it would take" to brute-force a password, and a 15-character random password is not necessarily "stronger" against all attacks considered together than an 8-character one. These include:
A coworker (for reference to the article) watching over your shoulder as you type;
A keylogger installed on the machine you're using;
A sniffer reading unencrypted network traffic;
The user types the password in cleartext in the "UserID" prompt instead of the "Password" prompt, and a third party sees it;
A security-camera records you typing your password;
The application stores passwords in the clear (perhaps for propogation to a single-sign-on system or for checking to make sure passwords aren't reused), and the clear-store gets compromised somehow;
The application stores hashes of passwords and someone gets a hold of the hashes and does a brute-force offline search;
An attacker tries random (or guessed) passwords until he gains access
All of these could happen the first day a password is used, or might not happen to a given password over the course of several years. It all depends on a lot of other factors, and ability to respond to a compromised password is equally as important as preventing it in the first place. Here are some ideas for how to make systems safer:
In new applications, passwords should be stored salted and hashed, and raw access to the password-store should be restricted;
Login failures should be logged and investigated, and users should have easy (read-only) access to their own login history and other accounting data;
Timed lockouts should be implemented, so that the number of keys a given attacker can try before being IP-blocked or physically apprehended is less that (say) 10;
Once the above are in place, a suggestion or requirement that users choose (or use) long, cryptographically-random passwords is perfectly reasonable. Arbitrary tests ostensibly designed to "prevent weak passwords" do not necessarily do so in a cryptographic sense, but have the fringe benefit of preventing some users from using the same password with this organization and another one with competing interests.
I can think of one situation where an organization might want to force password expiry: let's say the organization's accounts are used to control access to some shared resource that is also useful to people outside the organization (like an Internet-dialin mode pool or full-text access to an online journal subscription). An organization-member "helps out" his friend/family-member/roommate/whatever by typing his password in for the other person in Windows Dial-Up Networking or in the "Remember this Password" box of IE or Mozilla. If the password is never changed, the fourth party could still be getting a free ride several years later.
Even if users are sharing their passwords, forcing users to change their passwords doesn't solve the fundamental problem. Sure, the first time such a policy is tried in an organization that's been really lax it might cut recreational use of the modem-pool by 90%, but restricting users to one login at a time on a certain class of resources could do the same thing. It also sounds like the systems mentioned in the article tend to be high-security systems that wouldn't be used for such peripheral functions, anyway. Finally, the idea behind UserID/password authentication systems is that the user is willing to be responsible for the security of his own password; if that's not a valid assumption, the organization should look into physical tokens, biometric identifiers, or old-style non-uid-keyed passwords ("The password for the week is Charlie Seven Foxtrot Niner; write it down!")
Reusing passwords is a reasonable way to save frustration and memory-capacity from time to time; you just have to be smart about it. Of course I wouldn't use the same password for my primary e-mail account as for some random resume-listing service I had never heard of before, but (just as an example - I don't actually use Hotmail) I might use the same password for hotmail.com and AOL, with different user IDs.
When I'm adding a test account to a network server for short-term use, I might only use a four- or five-character password, since I'll disable the account soon anyway. My own passwords are longer, and several of them were generated by rolling dice. I hope I never work at a place with mandatory monthly password-changes, because those dice get lost all the time...
The expense of verifying real-world identities is why there aren't free SSL certs out there...
Actually, CAcert gives out free SSL certificates, if you can successfully interact with their web of trust.
Now, the PGP Global directory could certainly be subject to man-in-the-middle attacks if a malicious third party can actively read and respond to at least some of your incoming e-mail. That party could upload a bogus key and respond to the confirmation-request for you, then read things sent to you. Of course you'd find out when you saw strange unreadable signed messages coming to your account...
I also don't like the essage I got from the beta keyserver after I submitted my key today:
To ensure that your PGP software trusts keys verified by this directory, you must download and trust this directory's Verification Key.
Download the Verification Key
After downloading, import the Verification Key into your PGP software. Then, sign the key with your key and mark it as Trusted. Please see the documentation for your PGP software for specific instructions on trusting a key.
The directory seems like a highter-quality way to get keys, but I don't want to trust it *that* much; on the other hand, the Key Verification Policy seems to cover the same concerns that have been expressed here.
Actually a central repositor can add security. For instance, if I recieve e-mail fron juansanchez11@yahoo.com.mx, and it's not PGP signed (or I can't verify a chain of trust from known signatures), I don't really know anything about who sent it. If I examine the headers (at least after SPF is implemented), I can determine whether or not someone actually used the Yahoo service to send it, but I still have no idea *who* sent it. I don't even know whether they read their email, and I have no clue as to whether their name really is "Juan Sánchez". The new PGP.com free directory will make it a little bit faster to check whether the e-mail address part of a UID really is a valid e-mail address.
On the other hand, consider the address weisong@cs.wayne.edu. Visit www.cs.wayne.edu/~weisong, and you'll see his homepage. Look at the CS deprtment's list of faculty, and you see a link to that page. Wayne State University is an accredited institution listed, among other places, on the U.S. News & World Report site, and their campus directory has a link to their CS department. Since Dr. Shi is a professor, the department probably did a minimal background-check before hiring him, and you can trust his identity (at least minimally) based on his e-mail address.
Incidentally, I'm sure this directory would be useful to Dr. Shi; even though he teaches computer security, he's lost the passphrase or digital private key for all four of his public PGP keys, and he either never generated or subsequently lost the corresponding revocation certificates as well.
Spelling errors aren't the only ones that result when people don't proofread properly. A local paper routinely spells "façade" as "faÂade", probably because the original author uses Word (with auto-correct turned on) and then they pass it through some incompletely-implemented format-converter.
I think that southern Arizona, Nevada and California ought to be reunited with Mexico, but I'm not going to censor a video game that depicts any other situation. Furthermore, I don't expect either country to carry this out by invading the other; I think it will hapen as a result of the democratic process in both countries.
About a year ago, I was talking with a US Army recruiter about enlisting in the US Army. I got as far as MEPS. I passed the ASVAB and the physical, but they denied me enlistment after the security interview, which started out as a 10-page written questionnaire.
I answered "yes" to several questions that they wanted me to answer "no" to, but there were two that especially seemed to require a lot of "further clarification":
On the last page, just before a long affirmation about "this knowledge is true to the best of my knowledge and belief...", etc., etc., there was a question about like "Have you ever [...] misused [...] an information-technology resource?" I said "yes", and mentioned something that hadn't made my teachers happy during high school, about nine years before; I later found out that the high-school's disciplinary records have been destroyed from that time. However, if you think about it, downloading an illegal copy of a popular song off KaZaa is a forbidden use of an information-technology resource; I suspect the majority of the kids who did that stuff in Abu Ghraib had been regular KaZaa users...
The other thing was that I had visited a professional counsellor or therapist several times, all within a year or two, plus or minus, of the computer-related incident. They decided to totally misread the examining doctor's statement for something that was not in the record, and disqualify me as medically unfit by reason of depression (apparently). Of course, perhaps a college graduate who wants to join the Army is crazy. It may be that anyone who wants to join the Army has a little something wrong with them...
Just to answer certain questions in advance: Yes, I observe the Word of Wisdom (sorry about the JavaScript-wrapped text); drug use has always been a complete non-issue. No, I do not beat my wife. That's right, I did not go to BYU; I went to MSU instead, and they do not have an honor code that requires clean-shavenness. I know the Army has a dress code, and I told the recruiter that I would be perfectly willing to abide by it once enlisted; I had obeyed a similar dress code for two years as a missionary. Yes, I should probably be doing something else besides responding in detail to five-hour-old Slashdot postings
What's with the OP saying the screensaver was "too successful"? Either DOS is OK, or it isn't. One dude trying to login to a military installation's server by trying random passwords over a 300-baud modem is still deliberately endangering national security. Spray-painting swear-words on the back wall of your neighbor's house is still vandalism even if he wears a Nazi uniform to work every day (or he wears a pink dress, or he stands on his front porch and reads the bible out loud, or he knocks on your door once a month to offer you discount Amway cleaning products, or he knocks on your door once a month to offer your son free pot...)
I have experience with doing something that was, in some sense, a DoS attack. Of course, I had forgotten to set the evil bit...
The professor of a class I'm taking recently told us to be careful about what screen-savers we download and run; appparently he'd seen some unusual ones in his lab, and he was worried about viruses. His advice might be relevant to the Lycos screensaver, too.
Seriously, folks, doesn't anyone remember the promises of the four-day work week because of the 'efficiency' of computers and automation? It never works that way.
I'm a college student, and I go to class four days a week. When I was in the undergrad program at a different university, most of my classes were half-empty on Friday at noon and two-thirds empty on Friday at 3pm; now my department doesn't even bother scheduling anything on Fridays. Sure, the library is open Friday-Saturday-Sunday and the computer-labs are open Friday-Saturday, but a full-time student could go to school just four days a week. He can telecommute (take web classes?), too.
I'm runnig Debian stable on a server, but the current version of MySQL is 3.23.49, so I installed the official 4.1-gamma binary as soon as it was released. I'll probably install PHP 5 and MySQL 5 as soon as they're both considered stable by their respective developers. A distribution is a base system, but it won't necessarily have everything needed for a specific application.
BTW, I recently had a less-than-stellar experience with RedHat Enterprise WS; I ended up downloading a lot of packages from Debian and converting them with Alien just to get decent functionality.
Why does name, address, birth date, gender, race and Social Security have to do with this obstensible goals?
Social Security is a useful unique identifier, but (as suggested elsewhere) a hash might be better. (i.e., MD5(CONCAT(ssn,"National Database ID, authority 465-117"))
Name has no reason being in the database given the stated purposes. It was probably included to avoid the consequences of data-entry errors on the social-security number.
Address is possibly useful for research purposes, but not the full address; it should be limited to city, county, zip, state.
Race and gender are needed to track compliance with Affirmative Action policies, I'm sure. Why not religion? Sexual orientation? Political party?
Birth date is important, but in such a database it could be rounded to the nearest week with no bad consequences.
Expressing field of study will be interesting, although standardized-testing and financial-aid organizations have probably already solved that problem.
In short, I can see that central collection of this information would be interesting, and the same information is already collected on the majority of enrolled students anyway, but ideally a lot of safeguards would be put into the system to avoid unautthorized use of the data.
It's true that, unlike in Java (JDBC) or Perl (DBI), the most-common idiom for database development in PHP uses database-specific function-calls. However, porting an application to a different database often requires rewriting code anyway, and a lot of the functions are so similar that one could make the change with search-and-replace; look at these pages in the PHP documentation:
Slashdot Mirror
In September 2001, I wondered whether the C.I.A., or perhaps some renegade arm of the U.S. Army/Navy/Air Force, had instigated the attacks in order to immediately double their top-secret budget. Naah... no American would ever do something like that, right?
Then again, as far as I know, all the executives at Enron were U.S. citizens, and so were the officers who performed the notorious interrogations at Abu Ghraib. In the 1980s, the U.S. government secretly sold arms all over the world to renegade governments and rebels who were thought to be preventing the spread of Communism. Who knows what really goes on in government departments before the papers are shredded and the tapes erased?
Why carry it? Just install a flatscreen monitor and waterproof keyboard, and a wall-mounted box running VNC or something. In fact, if you just want to read the news, all you need is a web browser.
I wonder if Visa is doing things like this to make the merchants happy -- after all, those are their actual customers (although consumers are the banks' customers, which may be why no bank wants to issue these cards.) Consider how checkout with a credit card is supposed to work now:
I think Visa wants merchants to think about how they could make the process less labour-intensive; for instance, this could be combined with RFID on items as follows:
- Customer picks up goods;
- Customer walks out of store;
- Profit!!!
(Customer recieves a charge on a random one of her several wireless-chip-based cards; that is her only reciept.)This might be especially popular for souvenir shops at special events; I recently worked on the cleaning-crew for one, and they were doing several things to maximize customer flow, like putting the entrance and exit at opposite sides of the store, and pricing everything in whole dollars with sales tax included (to the sales personnel wouldn't have to make change). A bar might use this system to collect their cover-charge, too. As for myself, I stay away from such places.
Most LDAP directories are used to keep track of people; therefore there is an InternetOrgPerson type which (if I remember rightly) has the following attributes by default:
- CommonName (i.e., userID)
- Full name
- Password (can be stored with both Windows and Unix encryption,
or in plaintext)
- Telephone number(s)
- Mailing address(es)
- JPEG photo
- e-mail address
- user ID #
- home directory (?), shell (?) (these might be in some other type)
However, LDAP types are extensible, so you could create a new type to represent employees, inventory, or even projects, or you could extend an existing type. For instance, you might want to add some of the following to InternetOrgPerson (if they're not already there):- GPG public key
- instant-messaging ID
- ID badge number
It's even possible to use an SQL or legacy-system database as a backend for OpenLDAP with some custom coding, although I'm sure a lot of people who use it don't bother.So that's what's in the directory. You might still ask, "what is it used for?"
Firstly, Windows, Netware, Solaris and Linux can all be told to get their login information from an LDAP directory. This means that (if it works) someone only needs one account in an organization, that their Windows password is automatically the same as their Unix password, etc. It does not mean that they need to use the same home directory on all systems; but home directories can be automatically created by login scripts. NIS+ was a Unix-only way to distribute just the information found in /etc/passwd; LDAP
is cross-platform.
Secondly, some E-mail clients (specifically Netscape, its derivatives, and Outlook; I don't have experience to speak for others) can treat an LDAP directory as an extension of the address-book. That sure beats running down the hall and referring to a printed list every time you want to e-mail someone or call them on the phone and only remember their name.
Of course, if your "organization" is one person working on ten computers in a family-member's basement, LDAP probably isn't worth the effort.
I think you can still use routine logs as evidence. It helps if your AUPs or the login banner says something like "all connections are logged"; then you can at least say in court that "so-and-so tried to connect on such-and-such a date". If you're an ISP under a DOS attack, you are obviously a party to the communication; but you aren't expected to read the e-mail that comes through to decide whether your customers are cheating on their spouses.
Secondly, a regular desktop computer that's always-on can provide resources (CPU, disk space, ...) to the network, so it isn't such a loss to leave it on.
Finally, Unix window managers (starting with CDE, which is about 14 years old) support "saving a session". This means I can log off one computer, walk down the hall, log in on another, and get my terminal windows and (some) applications back in the exact same place where they were before. If that's not good enough, you can use VNC to save your application-windows on a virtual desktop exactly where you want them.
Note that {u0440 u0430 u0443 u0440 u0430} spells "paypa", but there's no Cyrillic letter that really looks like an "l" when printed.
However, it would also help if the domain registries weeded out garbage domain-names, and if owners of high-profile domain names exercised due diligence in looking for attempts to get a domain that looked like their own trademark in a typical Unicode font. This isn't just a browser issue.
Netscape Navigator 6 running under Solaris crashes when viewing that page.
Several of my family-members share an AOL dial-in account and use AOL primary email addresses. I don't know if they've ever read or posted to Usenet. Since I don't subscribe to AOL, I'm not sure if I have a say in the matter. I'm not happy about this, but I can understand whay I might drop Usenet too if I were AOL.
I'll aggree that 98% of the newsgroups are 98% spam, and the 2% that aren't (such as comp.lang.c) are 80% or more flame-wars and other garbage.
Furthermore, participating in Usenet with an unmasked email address is an invitation to recieve a lot of unsolicited e-mail. AOL has been fighting spam for some time.
Finally, Usenet (like IRC) is a sort-of peer-to-peer model that doesn't really fit in the modern Internet. Soemone can publish something by putting it on their website. For many people, e-mail will get to its recipient in under a minute; why deal with the propogation delays of hours or more that Usenet offers? RSS feeds, IM, true peer-to-peer clients, cheap or free personal websites, slashcode/PHPbb, listman... each of these is a better solution to some part of what Usenet used to be used for.
Nevertheless, I won't say Usenet is permanently dead. There are other sites besides groups.google.com that provide access to Usenet postings. There is promise in the other direction too. For istance, I might actually fire up an old newsreader like trn if I knew that Slashdot was putting its site on Usenet.
I don't think this is really going to cause much cash expenditure as such -- it's more of a "now you can't blame us" memo. Of course, an air-traffic controller's time is probably worth something, and so is the time of the police-officer who ends up reading the report, but police follow up low-priority incidents all the time. Besides, the person responsible for the government spending said cash is the yahoo who tries to shine a high-powered laser at an airplane. What would you do if you were driving down an interstate highway and someone shined a laser at you from an overpass?
Seriously, once in a while I draw diagrams of things like this in my spare time, but having five or ten different services running the entire length of a 700-mile corridor does sound like colossal boondoggle. It also sounds like an invitation to terrorist attack.
A 4,000-mile road would have to cover a longer path; say from the Hudson Bay to Acapulco, going through Mexico City, Houston, Chicago and Milwaukee on the way.
When I took an OpenGL programming class two years ago, people were still calling the room "the SGI lab" and the monitors might have originally been hooked up to Indy workstations; however, the computers actually in there were dual-Pentium boxes running Windows 2k Workstation with some version of Visual C++. As a result, I've never written an OpenGL program that didn't require MFC (which is a shame, because I otherwise do new development on Linux and XFree86 has good OpenGL support these days).
- A coworker (for reference to the article) watching over your shoulder as you type;
- A keylogger installed on the machine you're using;
- A sniffer reading unencrypted network traffic;
- The user types the password in cleartext in the "UserID" prompt instead of the "Password" prompt, and a third party sees it;
- A security-camera records you typing your password;
- The application stores passwords in the clear (perhaps for propogation to a single-sign-on system or for checking to make sure passwords aren't reused), and the clear-store gets compromised somehow;
- The application stores hashes of passwords and someone gets a hold of the hashes and does a brute-force offline search;
- An attacker tries random (or guessed) passwords until he gains access
All of these could happen the first day a password is used, or might not happen to a given password over the course of several years. It all depends on a lot of other factors, and ability to respond to a compromised password is equally as important as preventing it in the first place. Here are some ideas for how to make systems safer:- In new applications, passwords should be stored salted and hashed, and raw access to the password-store should be restricted;
- Login failures should be logged and investigated, and users should have easy (read-only) access to their own login history and other accounting data;
- Timed lockouts should be implemented, so that the number of keys a given attacker can try before being IP-blocked or physically apprehended is less that (say) 10;
- Once the above are in place, a suggestion or requirement that users choose (or use) long, cryptographically-random passwords is perfectly reasonable. Arbitrary tests ostensibly designed to "prevent weak passwords" do not necessarily do so in a cryptographic sense, but have the fringe benefit of preventing some users from using the same password with this organization and another one with competing interests.
I can think of one situation where an organization might want to force password expiry: let's say the organization's accounts are used to control access to some shared resource that is also useful to people outside the organization (like an Internet-dialin mode pool or full-text access to an online journal subscription). An organization-member "helps out" his friend/family-member/roommate/whatever by typing his password in for the other person in Windows Dial-Up Networking or in the "Remember this Password" box of IE or Mozilla. If the password is never changed, the fourth party could still be getting a free ride several years later.Even if users are sharing their passwords, forcing users to change their passwords doesn't solve the fundamental problem. Sure, the first time such a policy is tried in an organization that's been really lax it might cut recreational use of the modem-pool by 90%, but restricting users to one login at a time on a certain class of resources could do the same thing. It also sounds like the systems mentioned in the article tend to be high-security systems that wouldn't be used for such peripheral functions, anyway. Finally, the idea behind UserID/password authentication systems is that the user is willing to be responsible for the security of his own password; if that's not a valid assumption, the organization should look into physical tokens, biometric identifiers, or old-style non-uid-keyed passwords ("The password for the week is Charlie Seven Foxtrot Niner; write it down!")
When I'm adding a test account to a network server for short-term use, I might only use a four- or five-character password, since I'll disable the account soon anyway. My own passwords are longer, and several of them were generated by rolling dice. I hope I never work at a place with mandatory monthly password-changes, because those dice get lost all the time...
That's what Sender Policy Framework and DomainKeys are designed to stop.
The expense of verifying real-world identities is why there aren't free SSL certs out there...
Actually, CAcert gives out free SSL certificates, if you can successfully interact with their web of trust.
Now, the PGP Global directory could certainly be subject to man-in-the-middle attacks if a malicious third party can actively read and respond to at least some of your incoming e-mail. That party could upload a bogus key and respond to the confirmation-request for you, then read things sent to you. Of course you'd find out when you saw strange unreadable signed messages coming to your account...
I also don't like the essage I got from the beta keyserver after I submitted my key today:
The directory seems like a highter-quality way to get keys, but I don't want to trust it *that* much; on the other hand, the Key Verification Policy seems to cover the same concerns that have been expressed here.
On the other hand, consider the address weisong@cs.wayne.edu. Visit www.cs.wayne.edu/~weisong, and you'll see his homepage. Look at the CS deprtment's list of faculty, and you see a link to that page. Wayne State University is an accredited institution listed, among other places, on the U.S. News & World Report site, and their campus directory has a link to their CS department. Since Dr. Shi is a professor, the department probably did a minimal background-check before hiring him, and you can trust his identity (at least minimally) based on his e-mail address.
Incidentally, I'm sure this directory would be useful to Dr. Shi; even though he teaches computer security, he's lost the passphrase or digital private key for all four of his public PGP keys, and he either never generated or subsequently lost the corresponding revocation certificates as well.
Spelling errors aren't the only ones that result when people don't proofread properly. A local paper routinely spells "façade" as "faÂade", probably because the original author uses Word (with auto-correct turned on) and then they pass it through some incompletely-implemented format-converter.
I think that southern Arizona, Nevada and California ought to be reunited with Mexico, but I'm not going to censor a video game that depicts any other situation. Furthermore, I don't expect either country to carry this out by invading the other; I think it will hapen as a result of the democratic process in both countries.
About a year ago, I was talking with a US Army recruiter about enlisting in the US Army. I got as far as MEPS. I passed the ASVAB and the physical, but they denied me enlistment after the security interview, which started out as a 10-page written questionnaire.
I answered "yes" to several questions that they wanted me to answer "no" to, but there were two that especially seemed to require a lot of "further clarification":
- On the last page, just before a long affirmation about "this knowledge is true to the best of my knowledge and belief...", etc., etc., there was a question about like "Have you ever [...] misused [...] an information-technology resource?" I said "yes", and mentioned something that hadn't made my teachers happy during high school, about nine years before; I later found out that the high-school's disciplinary records have been destroyed from that time. However, if you think about it, downloading an illegal copy of a popular song off KaZaa is a forbidden use of an information-technology resource; I suspect the majority of the kids who did that stuff in Abu Ghraib had been regular KaZaa users...
- The other thing was that I had visited a professional counsellor or therapist several times, all within a year or two, plus or minus, of the computer-related incident. They decided to totally misread the examining doctor's statement for something that was not in the record, and disqualify me as medically unfit by reason of depression (apparently). Of course, perhaps a college graduate who wants to join the Army is crazy. It may be that anyone who wants to join the Army has a little something wrong with them...
Just to answer certain questions in advance: Yes, I observe the Word of Wisdom (sorry about the JavaScript-wrapped text); drug use has always been a complete non-issue. No, I do not beat my wife. That's right, I did not go to BYU; I went to MSU instead, and they do not have an honor code that requires clean-shavenness. I know the Army has a dress code, and I told the recruiter that I would be perfectly willing to abide by it once enlisted; I had obeyed a similar dress code for two years as a missionary. Yes, I should probably be doing something else besides responding in detail to five-hour-old Slashdot postingsI have experience with doing something that was, in some sense, a DoS attack. Of course, I had forgotten to set the evil bit...
The professor of a class I'm taking recently told us to be careful about what screen-savers we download and run; appparently he'd seen some unusual ones in his lab, and he was worried about viruses. His advice might be relevant to the Lycos screensaver, too.
I'm a college student, and I go to class four days a week. When I was in the undergrad program at a different university, most of my classes were half-empty on Friday at noon and two-thirds empty on Friday at 3pm; now my department doesn't even bother scheduling anything on Fridays. Sure, the library is open Friday-Saturday-Sunday and the computer-labs are open Friday-Saturday, but a full-time student could go to school just four days a week. He can telecommute (take web classes?), too.
5-day-a-week jobs are so 20th-century...
BTW, I recently had a less-than-stellar experience with RedHat Enterprise WS; I ended up downloading a lot of packages from Debian and converting them with Alien just to get decent functionality.
--
DLL
Social Security is a useful unique identifier, but (as suggested elsewhere) a hash might be better. (i.e., MD5(CONCAT(ssn,"National Database ID, authority 465-117"))
Name has no reason being in the database given the stated purposes. It was probably included to avoid the consequences of data-entry errors on the social-security number.
Address is possibly useful for research purposes, but not the full address; it should be limited to city, county, zip, state.
Race and gender are needed to track compliance with Affirmative Action policies, I'm sure. Why not religion? Sexual orientation? Political party?
Birth date is important, but in such a database it could be rounded to the nearest week with no bad consequences.
Expressing field of study will be interesting, although standardized-testing and financial-aid organizations have probably already solved that problem.
In short, I can see that central collection of this information would be interesting, and the same information is already collected on the majority of enrolled students anyway, but ideally a lot of safeguards would be put into the system to avoid unautthorized use of the data.