Why use alphabet soup in the name when you can fully exploit the capabilities of DNS?
What I did on a slightly smaller network than the one you're proposing is this:
Assign subdomains to different networks. They should be completely utilitarian.
Assign names to each machine in each network. I follow a theme for each.
When a machine is in two networks, define a "main" network interface. Name it using its main network team (bonus points if you manage to assign a name belonging to both themes).
Assign ALIASES to each machine, one for each function.
As an example: you have two offices (Boston and Miami). In each you have three roles: printserver, fileserver and gateway, and one machine in Miami and two in Boston. The themes would be Maniac Mansion and BOFHs. You end up with:
Boston (domain bos.example.com): edna IN A 192.168.1.1 bernard IN A 192.168.1.2 hoagie IN A 192.168.1.3 gateway IN CNAME ed
fileserver IN CNAME bernard
printserver IN CNAME hoagie
Miami (domain mia.example.com): simon IN A 192.168.2.1pitr IN A 192.168.2.2 gateway IN CNAME simon
printserver IN CNAME pitr
fileserver IN CNAME pitr
You then give your users only the alias.
Doing things that way, you can easily locate each server. You can make a reference to a particular server easily and you can shuffle tasks around just by changing CNAMEs. The users can access everything with little hassle (fileserver for the local fileserver or full FQDN for the CNAME for a remote one). You can also delegate easily and should you need it, you can add extra levels. You could add country codes after example.com in case you open an office in Vancouver changing your hierarchy your names to:
WTF is happening to slashdot? When I mean plain old text, I should not need to type those stupid html tags! Sorry about the odd spacing in the zone files.
Public key encryption is susceptible to man in the middle attacks when using an anonymous key exchange. Since Alice does not know who is she talking to, she could be talking to Bob (as expected) or Trudy (an impostor). It is important that Trudy can ADD/DELETE/CHANGE the messages that go by. If Trudy is not changing anything, eventually Alice and Bob will get a common key and Trudy is screwed.
When Alice makes an anonymous key exchange, if she does it with Bob, then everything is fine, Trudy cannot look into the channel. The problem is that Alice might have negociated a key exchange with Trudy. She really does not know whether she is talking to Bob or Trudy (and if Trudy is a smart girl, she'll do the same with Bob so Alice and Bob both speak via Trudy instead of directly).
Now, let's see a TLS-like negotiation from Alice's side (Bob being the server).
Participants: Alice, The other side (TOS, Bob in theory)
Act one: signed by a bogus CA (that Alice does not recognize)
TOS: Here's my certificate. You'll see it says I'm Bob. Alice: Yes, so it does. But I do not trust what scammers inc. says. You're not Bob! (Alice hangs up)
Act two: Trudy tries to use Bob's certificate without the key
TOS: Here's my certificate. You'll see it says I'm Bob. Alice: Indeed you are! Here is my KEX. TOS: Here's my KEX Alice: Great, we now have a common key! Now, could you sign a hash of it with Bob's key? TOS: ummmmm, sorry I left the key in my other pants........ Alice: You're not Bob, you just took his certificate! (Alice hangs up)
Act three: Trudy get a certificate from the CA
TOS: Here's my certificate. You'll see it says I'm B0b. Alice: B0b, with a zero? Sorry, you're not the person I wanted to talk to. (Alice hangs up)
Act four: the real McBOB
TOS: Here's my certificate. You'll see it says I'm Bob. Alice: Indeed you are! Here is my KEX. TOS: Here's my KEX Alice: Great, we now have a common key (K)! Now, could you sign a hash of it with Bob's key? TOS: Sure, here's the signature.
Alice verifies it's a signature of H(K), so she knows whoever owns the certificate knows K. Alice verified the name in the certificate, so she know someone called "Bob" owns the key used to sign K above. Alice verified that the signature belongs to an authority she trusts, so she knows that nobody messed with the certificate after it was issued. Alice knows the CA to be trustworthy enough to check that the person claiming to be Bob is really Bob before signing the certificate.
Now, your questions:
1) I thought with public key encryption you only needed public keys available so there was no danger of such MITM attacks? Doesn't SSL use public key encryption?
There are anonymous methods for key exchange, if you use them with an impostor, you will not know and a smart impostor can then hook you to your real partner, allowing him to observe the contents of your communication. Alternatively, he can just substitute your partner's key for his. If the attacker is passive, there's nothing he can do and he will be thwarted.
2) How does a certificate prevent a MITM attack during the key exchange process?
By forcing the partner to prove his identity signing a derivative of the key exchange, or the messages that form the key exchange. All of this, provided the certificate is the real thing and not a forgery made by the attacker. That's why it is important to have a CA. When you use a self signed certificate, you're basically doing act one. Of course if you got the real certificate (be it because your partner gave it to you or you just accepted it once and got lucky), you're back at act four (just like what happens with ssh keys).
I sometimes wonder why the designers of SSL mandated a certificate at the server end.
They did not.
From section A.5, rfc 4643:
The following cipher suites are used for completely anonymous
Diffie-Hellman communications in which neither party is
authenticated. Note that this mode is vulnerable to man-in-the-
middle attacks and is therefore deprecated.
There is one advantage when using a certificate, though. You can accept it and keep a copy, thus preventing an impostor from impersonating the site in the future (assuming you got the right cert the first time), just like ssh keys.
The problem with encryption is not the cracking of messages, but that they track who sends them to whom. I.E, if you send encrypted messages, you may end up having all your communications mapped.
And that's defeated (just as the GP said) by having everyone send everything encrypted. One thing is mapping the communications of one cipherpunk, but the game is not the same when that cipherpunk acts just as everyone else. You would have to map everyone's communication, a return to the current status quo, plus encryption for everyone.
Actually, I recall x86's real mode pages actually overlapped in the bus address ranges that they mapped to. So in this case number of pages * page size doesn't give total addressable real memory. Can't remember the actual numbers, however.
FYI, the segmentation used in x86 was like this:
0xFFFF segments of 0xFFFF bytes (64Ki segments of 64KiB).
It means that a segment starts every 16 bytes and is 64KiB long (and you have a lot of overlapping). By using segmentation you manage to handle 20 address lines with 16 bit registers, for a total of 1 MiB of memory. That's not counting highmem tricks (e.g. Segment 0xFFFF in theory can only be 16 bytes long, but it extends over the 1 MiB limit if you have the necessary lines).
Unless you're sending tcp segments on top of those packets. In that case TCP's congestion control algorithms will make sure your performance drops to the floor.
I've been analyzing a 4 Mbps link recently with a 0.1% to 0.7% packet loss, and it does make a big difference. Having constant fast recoveries can convert a 4 Mbps link to a 400Kbps one real fast.
The most annoying bubble I've seen is a "Your device would be a lot faster if you connect it to a USB 2.0 port", when you do not have a USB 2.0 port anywhere.
It's like it wants to rub the fact that you didn't upgrade to USB 2.0 in your face.
Then again, the "I tried to install the drivers for your new usb device but I don't have enough privileges" popup is even more annoying. I guess windows 2000 just likes to go ahead and try to do things and fail instead of checking the situation before starting.
You should have talked to the administrator instead....they are hard to kill to enforce policy. Had I been the admin at your place of work, you would have gotten LARTed real bad.
That being said, I agree with you for other reasons.
I was an admin on a place with symantec corporate as the local antivirus. For some stupid reason it would also target "hack tools" and delete them. Being an admin, those "hack tools" are the tools of my trade, and that dumb piece of software would delete them as soon as I unpacked them.
The worst thing was that they had recently "enhanced" the control panel by adding groups. That meant that it was impossible to issue commands or policies to individual workstations, only groups. Basically, I ended all by myself in a group, with special privileges to disable my antivirus client (being the BOFH has its advantages). That is, until I installed SuSE 10, when the antivirus in my workstation got mothballed with the rest of the windows partition.
A good choice, sure. But there is another avenue of attack. SSH and SSL also generate temporary keys, nonces and such. An attacker that sniffed a session in the past could in theory analyze the captures and guess the session keys. With that, they could sniff your session. You might want to change your passwords too.
I've had an awful day at work, and it looks like tomorrow will be worse.
I carry a Palm 3. It's perfect as a PDA, it will work for weeks with a couple of AAA cells and I already have it.
If I got a beefier one, it would not have the same battery life (and with a proprietary battery), it'll probably have other stuff that I don't want and I'd have to pay for it. No point in replacing the right tool with the wrong one, and in any case I could do ssh via IR. A PDA is not a notebook, nor a workstation, nor a supercomputer.
I work as an admin, so I usually have control over the endpoint. If I don't, I usually have authority and a direct line to the local BOFH. I wouldn't even think of logging through an uncontrolled terminal (in fact, I've set things up so that I can't).
If you ever see me logging through a public terminal, it means that there's some HUGE emergency going on, or that I managed to convince everyone in the world to add a smartcard reader to his/her computer.
Sure, even the RFC warns about these types of attack.
Unlike the article poster, I don't access my system from public terminals. I also don't have direct root access, except from the console. In my case, it's another line of defense when su-ing. First I must access my system via SSH with public keys. Going root is precisely what I intend. In any case, I've only gone root from my other computer, a metre to the right of the server (yes, it's overkill, it all started as a joke, too).
It's great for accountability and to promote discipline. When you have to do such a thing to gain root, you think twice before escalating. At the same time you get a nice counter telling you how many escalations you did .
You won't get a more robust worked out solution than a IETF standard......
I don't have a mac, and I'm not experienced enough with *BSD to know exactly what to tell you, my explanation on Debian GNU/Linux will have to do.
First, let me tell you that this is not my first line of defense, I also use ssh pubkeys and I definitely do not log on public terminals. OPIE is just there in case someone pwns one supposedly trusted terminal.
What I do is I creatively use PAM. I installed PAM-OPIE on my system. It comes with a few userland apps (a password changing program and a one time password calculator) and an authentication module.
The next thing to do is to modify the pam configuration so it calls pam_opie.so as an authentication. I set it up so that inputting the correct one time password grants access, while leaving the regular password system as a fallback only when used on the local terminal.
# Sets up user limits, please uncomment and read/etc/security/limits.conf # to enable this functionality. # (Replaces the use of/etc/limits in old login) # session required pam_limits.so
The text above is part of my pam configuration for su. Basically, I tell pam that answering correctly to pam_opie grants access, no matter what. If I fail S/KEY (opie), the system checks whether I'm on the terminal or remotely. If I'm not on the terminal, no matter what password I use, it'll never grant access.
On the userland, OPIE has a program, called opiekey, that calculates the next set of one time passwords you will need. That's what you should use to generate your set of 100 passwords. I don't use it since I have a calculator with me (the PDA). In order to set your long time password, you use another program, called opiepasswd, pretty much like the normal passwd program.
I don't know what you're planning to use to access your system (I hope ssh or something secure), but you should change pam's configuration for that program so it does something like the example above.
Let's say you use SSH. You change/etc/pam.d/sshd (or your OSX equivalent) to something like the example above. Then you set sshd to ALLOW keyboard-interactive logon and nothing else (or better, keyboard-interactive AND pubkey at the same time). When you connect the ssh client should open a secure connection and the server should issue the challenge, and you send the correct response.
No need to use perl or anything, PAM is part of the basic authentication system (I think it is on BSDs except OpenBSD). You might need to download a copy of pam_opie, though (thanks to APT, that's trivial in debian, check with your package manager).
That's pretty much it. I've put pointers to the freebsd docs, and it can't be that different from linux. I guess it should be pretty similar in mac too (would have pointed you to the mac docs, but I don't know where to find them).
If you have any doubts, don't hesitate to ask.
BTW, while on vacation the only thing I concentrate on is getting a nice sun tan. The other posters are right telling you not to log on a public terminal and not logging in while on vacation. That's my advice.
Someone with a software keylogger will probably want to observe the mouse input, since those "virtual keyboards" used in banking sites are very common. They might not get it right, but it is a risk (and will get riskier if this method becomes widespread).
To get root access on my server, I use a one time password system(rfc 2289). I use a S/KEY calculator on a palm pilot, and PAM Opie on the server. The public terminal never sees a long term password, it never leaves the PDA.
Not much else to be said. Maybe you could also use a crypto token and asymetric crypto, but considering that you need drivers, I'd say it's not practical. You might still use some sort of somewhat disposable private/public key. That should defeat keyloggers, but you risk getting your key compromised (that's why it's disposable).
It won't look like rubbish. It will look like the product of a substitution cipher, that can be easily cracked by anyone with some wits and a basic notion of frequency analysis.
The difference is that in the first case, the data passes through a dumb machine that compresses, caches, etc. The result is cached like it is expected (RFC 2616 is pretty clear about that), even though it is done transparently. No need to keep logs about who downloaded what.
In this case, the data is explicitly mined, by a company interested in building a profile of each user. It doesn't say it is limited to web traffic only, only that "Nor does NebuAd record a user's visits to pornography or gaming sites or a user's interests in sensitive subjects -- such as bankruptcy or a medical condition such as AIDS.", which I doubt both on technical grounds and because it is a market and someone will want to take advantage and "The company said it processes but does not look into packets of information that include e-mail or pictures." which I think is in contradiction with other parts of the article and even if they didn't, it's a matter of time before they do.
Basically, it's the intent that counts. The ISP can intercept everything they want because they're in the middle. When they start doing so for reasons that are not part of maintaining the communications as specified (like forwarding, maybe firewalling and proxying depending on the conditions), alarms should go off.
If they did, then they would have broken the lock-in themselves. Nobody would buy MS Office "because everyone reads and writes.doc".
A few years later, the MS Office franchise would die of a thousand paper cuts, as people dissatisfied with MSO would migrate to other platforms. At the very least, it would force MS to reduce prices and enhance the product, just like what happened with IE.
I've been seeing lots of posts critisizing fingerprint authentication and how it is easily cracked, etc. You should (re)read TFA, because you're not getting the idea.
Those sticks are flawed not because the fingerprint sensor sucks, but because the authentication is made on the computer.
If I got it right, those sticks should work like this
You plug the stick
You put your finger on the sensor
The sensor reads your print and sends its data to the computer
The windows driver takes the data and decides whether it should give you access or not
If the print matches, IT SENDS WHAT IN ESSENCE IS AN UNLOCK COMMAND TO THE STICK
You access the private partition
The fact that the stick uses biometrics is irrelevant. With a design like that, it would have been vulnerable even if it had PIN, RSA keys or black magic. You can just bypass the security mechanism by sending the unlock command.
Essentialy, it has the same flaw as the secustik we saw last year.
Slashdot Mirror
Yes, I know I fucked up ed.bos.example.com, no need to tell me.
BTW, don't forget the backbone, it is a network too.
Why use alphabet soup in the name when you can fully exploit the capabilities of DNS?
What I did on a slightly smaller network than the one you're proposing is this:
As an example: you have two offices (Boston and Miami). In each you have three roles: printserver, fileserver and gateway, and one machine in Miami and two in Boston. The themes would be Maniac Mansion and BOFHs. You end up with:
Boston (domain bos.example.com):
edna IN A 192.168.1.1
bernard IN A 192.168.1.2
hoagie IN A 192.168.1.3
gateway IN CNAME ed
fileserver IN CNAME bernard
printserver IN CNAME hoagieMiami (domain mia.example.com):
printserver IN CNAME pitrsimon IN A 192.168.2.1pitr IN A 192.168.2.2
gateway IN CNAME simon
fileserver IN CNAME pitr
You then give your users only the alias.
Doing things that way, you can easily locate each server. You can make a reference to a particular server easily and you can shuffle tasks around just by changing CNAMEs. The users can access everything with little hassle (fileserver for the local fileserver or full FQDN for the CNAME for a remote one). You can also delegate easily and should you need it, you can add extra levels. You could add country codes after example.com in case you open an office in Vancouver changing your hierarchy your names to:
fileserver.bos.us.example.comprintserver.van.ca.example.com
or even add extra levels under the city names if you need:
fileserver.hq.bos.example.com
fileserver.researchlab.bos.example.com
WTF is happening to slashdot? When I mean plain old text, I should not need to type those stupid html tags! Sorry about the odd spacing in the zone files.
I'll answer that.
Public key encryption is susceptible to man in the middle attacks when using an anonymous key exchange. Since Alice does not know who is she talking to, she could be talking to Bob (as expected) or Trudy (an impostor). It is important that Trudy can ADD/DELETE/CHANGE the messages that go by. If Trudy is not changing anything, eventually Alice and Bob will get a common key and Trudy is screwed.
When Alice makes an anonymous key exchange, if she does it with Bob, then everything is fine, Trudy cannot look into the channel. The problem is that Alice might have negociated a key exchange with Trudy. She really does not know whether she is talking to Bob or Trudy (and if Trudy is a smart girl, she'll do the same with Bob so Alice and Bob both speak via Trudy instead of directly).
Now, let's see a TLS-like negotiation from Alice's side (Bob being the server).
Participants: Alice, The other side (TOS, Bob in theory)
Act one: signed by a bogus CA (that Alice does not recognize)
Act two: Trudy tries to use Bob's certificate without the key Act three: Trudy get a certificate from the CA Act four: the real McBOB Alice verifies it's a signature of H(K), so she knows whoever owns the certificate knows K.Alice verified the name in the certificate, so she know someone called "Bob" owns the key used to sign K above.
Alice verified that the signature belongs to an authority she trusts, so she knows that nobody messed with the certificate after it was issued.
Alice knows the CA to be trustworthy enough to check that the person claiming to be Bob is really Bob before signing the certificate.
Now, your questions:
There are anonymous methods for key exchange, if you use them with an impostor, you will not know and a smart impostor can then hook you to your real partner, allowing him to observe the contents of your communication.
Alternatively, he can just substitute your partner's key for his.
If the attacker is passive, there's nothing he can do and he will be thwarted.
By forcing the partner to prove his identity signing a derivative of the key exchange, or the messages that form the key exchange. All of this, provided the certificate is the real thing and not a forgery made by the attacker. That's why it is important to have a CA.
When you use a self signed certificate, you're basically doing act one. Of course if you got the real certificate (be it because your partner gave it to you or you just accepted it once and got lucky), you're back at act four (just like what happens with ssh keys).
I screwed up the rfc number.
It's 4346: "The Transport Layer Security (TLS) Protocol Version 1.1"
They did not.
From section A.5, rfc 4643:
The following cipher suites are used for completely anonymous
Diffie-Hellman communications in which neither party is
authenticated. Note that this mode is vulnerable to man-in-the-
middle attacks and is therefore deprecated.
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
There is one advantage when using a certificate, though. You can accept it and keep a copy, thus preventing an impostor from impersonating the site in the future (assuming you got the right cert the first time), just like ssh keys.
.xxx is a bad idea too. There's even a rfc explaining why it should not be used.
http://www.ietf.org/rfc/rfc3675.txt
And that's defeated (just as the GP said) by having everyone send everything encrypted. One thing is mapping the communications of one cipherpunk, but the game is not the same when that cipherpunk acts just as everyone else. You would have to map everyone's communication, a return to the current status quo, plus encryption for everyone.
FYI, the segmentation used in x86 was like this:
0xFFFF segments of 0xFFFF bytes (64Ki segments of 64KiB).
The memory address can be calculated as:
SEGM * 0x10 + OFFSET
for example:
DC00_ Segment Register (CS, DS, etc)
+
_ABCD Offset
-------
E6BCD Memory address (20 bits)
It means that a segment starts every 16 bytes and is 64KiB long (and you have a lot of overlapping). By using segmentation you manage to handle 20 address lines with 16 bit registers, for a total of 1 MiB of memory. That's not counting highmem tricks (e.g. Segment 0xFFFF in theory can only be 16 bytes long, but it extends over the 1 MiB limit if you have the necessary lines).
Unless you're sending tcp segments on top of those packets. In that case TCP's congestion control algorithms will make sure your performance drops to the floor.
I've been analyzing a 4 Mbps link recently with a 0.1% to 0.7% packet loss, and it does make a big difference. Having constant fast recoveries can convert a 4 Mbps link to a 400Kbps one real fast.
Hah. You call that annoying?
The most annoying bubble I've seen is a "Your device would be a lot faster if you connect it to a USB 2.0 port", when you do not have a USB 2.0 port anywhere.
It's like it wants to rub the fact that you didn't upgrade to USB 2.0 in your face.
Then again, the "I tried to install the drivers for your new usb device but I don't have enough privileges" popup is even more annoying. I guess windows 2000 just likes to go ahead and try to do things and fail instead of checking the situation before starting.
You should have talked to the administrator instead....they are hard to kill to enforce policy. Had I been the admin at your place of work, you would have gotten LARTed real bad.
That being said, I agree with you for other reasons.
I was an admin on a place with symantec corporate as the local antivirus. For some stupid reason it would also target "hack tools" and delete them. Being an admin, those "hack tools" are the tools of my trade, and that dumb piece of software would delete them as soon as I unpacked them.
The worst thing was that they had recently "enhanced" the control panel by adding groups. That meant that it was impossible to issue commands or policies to individual workstations, only groups. Basically, I ended all by myself in a group, with special privileges to disable my antivirus client (being the BOFH has its advantages). That is, until I installed SuSE 10, when the antivirus in my workstation got mothballed with the rest of the windows partition.
A good choice, sure. But there is another avenue of attack.
SSH and SSL also generate temporary keys, nonces and such. An attacker that sniffed a session in the past could in theory analyze the captures and guess the session keys. With that, they could sniff your session. You might want to change your passwords too.
I've had an awful day at work, and it looks like tomorrow will be worse.
It's still the number of the beast, you just have to use the longer version when calling from an overseas location.
I carry a Palm 3. It's perfect as a PDA, it will work for weeks with a couple of AAA cells and I already have it.
If I got a beefier one, it would not have the same battery life (and with a proprietary battery), it'll probably have other stuff that I don't want and I'd have to pay for it. No point in replacing the right tool with the wrong one, and in any case I could do ssh via IR. A PDA is not a notebook, nor a workstation, nor a supercomputer.
I work as an admin, so I usually have control over the endpoint. If I don't, I usually have authority and a direct line to the local BOFH. I wouldn't even think of logging through an uncontrolled terminal (in fact, I've set things up so that I can't).
If you ever see me logging through a public terminal, it means that there's some HUGE emergency going on, or that I managed to convince everyone in the world to add a smartcard reader to his/her computer.
Sure, even the RFC warns about these types of attack.
Unlike the article poster, I don't access my system from public terminals. I also don't have direct root access, except from the console. In my case, it's another line of defense when su-ing. First I must access my system via SSH with public keys. Going root is precisely what I intend. In any case, I've only gone root from my other computer, a metre to the right of the server (yes, it's overkill, it all started as a joke, too).
It's great for accountability and to promote discipline. When you have to do such a thing to gain root, you think twice before escalating. At the same time you get a nice counter telling you how many escalations you did .
Really?
I knew the had kerberos out of the box, but not S/KEY.
I'm an OBSD rookie. Got any pointers? I could use that information.
Thanks.
You won't get a more robust worked out solution than a IETF standard......
/etc/security/limits.conf /etc/limits in old login)
/etc/pam.d/sshd (or your OSX equivalent) to something like the example above. Then you set sshd to ALLOW keyboard-interactive logon and nothing else (or better, keyboard-interactive AND pubkey at the same time). When you connect the ssh client should open a secure connection and the server should issue the challenge, and you send the correct response.
I don't have a mac, and I'm not experienced enough with *BSD to know exactly what to tell you, my explanation on Debian GNU/Linux will have to do.
First, let me tell you that this is not my first line of defense, I also use ssh pubkeys and I definitely do not log on public terminals. OPIE is just there in case someone pwns one supposedly trusted terminal.
What I do is I creatively use PAM. I installed PAM-OPIE on my system. It comes with a few userland apps (a password changing program and a one time password calculator) and an authentication module.
The next thing to do is to modify the pam configuration so it calls pam_opie.so as an authentication. I set it up so that inputting the correct one time password grants access, while leaving the regular password system as a fallback only when used on the local terminal.
# Sets up user limits, please uncomment and read
# to enable this functionality.
# (Replaces the use of
# session required pam_limits.so
#Sistema hibrido opie-password
auth sufficient pam_opie.so
auth required pam_securetty.so
auth required pam_unix.so
The text above is part of my pam configuration for su. Basically, I tell pam that answering correctly to pam_opie grants access, no matter what. If I fail S/KEY (opie), the system checks whether I'm on the terminal or remotely. If I'm not on the terminal, no matter what password I use, it'll never grant access.
On the userland, OPIE has a program, called opiekey, that calculates the next set of one time passwords you will need. That's what you should use to generate your set of 100 passwords. I don't use it since I have a calculator with me (the PDA). In order to set your long time password, you use another program, called opiepasswd, pretty much like the normal passwd program.
I don't know what you're planning to use to access your system (I hope ssh or something secure), but you should change pam's configuration for that program so it does something like the example above.
Let's say you use SSH. You change
No need to use perl or anything, PAM is part of the basic authentication system (I think it is on BSDs except OpenBSD). You might need to download a copy of pam_opie, though (thanks to APT, that's trivial in debian, check with your package manager).
That's pretty much it. I've put pointers to the freebsd docs, and it can't be that different from linux. I guess it should be pretty similar in mac too (would have pointed you to the mac docs, but I don't know where to find them).
If you have any doubts, don't hesitate to ask.
BTW, while on vacation the only thing I concentrate on is getting a nice sun tan. The other posters are right telling you not to log on a public terminal and not logging in while on vacation. That's my advice.
Someone with a software keylogger will probably want to observe the mouse input, since those "virtual keyboards" used in banking sites are very common. They might not get it right, but it is a risk (and will get riskier if this method becomes widespread).
To get root access on my server, I use a one time password system(rfc 2289). I use a S/KEY calculator on a palm pilot, and PAM Opie on the server. The public terminal never sees a long term password, it never leaves the PDA.
Not much else to be said. Maybe you could also use a crypto token and asymetric crypto, but considering that you need drivers, I'd say it's not practical. You might still use some sort of somewhat disposable private/public key. That should defeat keyloggers, but you risk getting your key compromised (that's why it's disposable).
It won't look like rubbish. It will look like the product of a substitution cipher, that can be easily cracked by anyone with some wits and a basic notion of frequency analysis.
Let me add OTR messaging to the list.
Available for Pidgin (aka GAIM), Adium X, mICQ, Kopete, Miranda, Trillian and as a proxy for people that use other clients. Works on any IM network.
(I've been using it on GAIM for some time and I recommend it)
The difference is that in the first case, the data passes through a dumb machine that compresses, caches, etc. The result is cached like it is expected (RFC 2616 is pretty clear about that), even though it is done transparently. No need to keep logs about who downloaded what.
In this case, the data is explicitly mined, by a company interested in building a profile of each user. It doesn't say it is limited to web traffic only, only that "Nor does NebuAd record a user's visits to pornography or gaming sites or a user's interests in sensitive subjects -- such as bankruptcy or a medical condition such as AIDS.", which I doubt both on technical grounds and because it is a market and someone will want to take advantage and "The company said it processes but does not look into packets of information that include e-mail or pictures." which I think is in contradiction with other parts of the article and even if they didn't, it's a matter of time before they do.
Basically, it's the intent that counts. The ISP can intercept everything they want because they're in the middle. When they start doing so for reasons that are not part of maintaining the communications as specified (like forwarding, maybe firewalling and proxying depending on the conditions), alarms should go off.
If they did, then they would have broken the lock-in themselves. Nobody would buy MS Office "because everyone reads and writes .doc".
A few years later, the MS Office franchise would die of a thousand paper cuts, as people dissatisfied with MSO would migrate to other platforms. At the very least, it would force MS to reduce prices and enhance the product, just like what happened with IE.
I don't think buying voters, setting very short deadlines for comments, and stuffing meetings is standard procedure.
Those sticks are flawed not because the fingerprint sensor sucks, but because the authentication is made on the computer.
If I got it right, those sticks should work like this
The fact that the stick uses biometrics is irrelevant. With a design like that, it would have been vulnerable even if it had PIN, RSA keys or black magic. You can just bypass the security mechanism by sending the unlock command.
Essentialy, it has the same flaw as the secustik we saw last year.