$10,000 is a lot. Maybe make real but effectively no-op customizations to each legit copy so each is unique, including a banner that says whose copy it is. If it later shows up stolen you know whom to sue. Add some phone-home statistics and you know how much to sue them for. Do a little runtime checking on the visible ID banner to make hard to remove.
> The problem is, is that if you allow people to choose any password > they want, many will choose a short, easy to guess password.
A good password needs to have some significant randomness in it and people are really bad judges of randomness. Even some pretty nerdly folks can be really näive on this.
> I guess if they don't have to write it down, then it's more secure > than a 20 character password which they do write down, but it is > still very insecure.
What's wrong with writing down a password? Honestly, what is so wrong with it? Yes, the proverbial postit note with the password stuck on the edge of the monitor provides nearly* no security for a foe who is sitting front of the computer, but the monitor is probably in your home (where you store other valuable things), or in your office (where a stranger walking in might be noticed by a coworker). The recent scary innovation is that the bad guy who guesses that your password is "Frodo" might be anywhere in the world where there is an internet connection, which is a lot bigger than the small space in front of your desk.
To have good security one has to stop and consider what the problem is. What are you trying to protect, from whom, for how long?
Take the person with the password "jumbo-joker-basil" (a password used for only one purpose) written on a piece of paper in his wallet, and compare him with the person who uses a Really Good Password like "Oog3gear" in many places but doesn't write it down. Which is better?
The jumbo-joker-basil password that gets written down is probably more secure. The risk of someone stealing the wallet, knowing the significance of jumbo-joker-basil, being interested in doing something with it, and actually doing something about it before the person with the lost wallet can get the password changed, is limited. On the other side, the chances that someone who *is* interested in passwords manages to compromise some other account that also uses the Oog3gear, is very real, and when it happens, unlike the stolen wallet example, the authorized user probably won't know the password has been stolen and won't know to quickly change it. Writing down a password, if it makes it possible to not reuse passwords, is almost always a worthy tradeoff--particularly if it can be "written down" encrypted in a PDA with something like the free Palm application "Keyring".
As for the two example passwords above, disregarding whether they are reused or written down, which is more secure? The one with the most entropy in it. Which is that? "jumbo-joker-basil"
"Oog3gear" is a pretty weak password. It is probably OK if your foe can only try guessing passwords at a slow rate, but if your foe gets a chance to brute force it quickly (i.e., if used for cryptography) it is terrible!
This password was generated by pwgen in its default mode. In this mode it produces passwords that are:
- Exactly 8 characters long,
- Have exactly one capital letter,
- Have exactly one numerical digit, and
- Are pretty easily pronounceable for an english speaker.
Because of the redundancy in english-like words, and because of the other constraints on pwgen output, the number of possible outputs from pwgen is not as large as one might first guess.
But the real killer for pwgen is that by default it spits out a whole screen of suggestions and a human gets to pick one "at random". I have not seen a scientific study on how subjects pick from this list, but *my* tendency is to pick an easy to remember item, one that includes a real english word, one with repetition, one that is capitalized in a language-like way. The result is that the universe of passwords actually chosen from pwgen output are likely a small, relatively predictable, set. I once estimated that the number of bits of entopy in a typical pw
I bought a PHR-250CC from Newegg (I think it was). I also bought a 2.5" drive that installed rather easily. (You need a very small phillips screw driver and you need to slide it together with the correct edge going into the correct slot.)
It has both USB 2.0 and 1394 jacks. It comes with a heavy USB cable that will power it off my notebook, but it also comes with a second USB-to-power connector cable for computers that put off less power. It also comes with a heavy 1394 cable that presumably will power it if you have a 6-pin Firewire jack.
It works great with my Linux machine, I get 27 MB/s on it. I haven't tried the 1394, but at least some of the time this model is marketed under the Macally name, so I bet it works fine with a Macintosh.
The drive is mostly metal. I don't coddle it, but it seems to stand up well. I'd buy another.
You can also use GNU keyring to encrypt important bits, and if you do an entire backup of your palm to the card you can put the card in any Palm you can get your hands on, and the GNU keyring software will be there too, ready to go.
Also, if you get a big SD card you can also use a computer to copy data onto it that the Palm doesn't necessarily know about. (Do the Palm backup first, note the directory structure, don't disturb it with your computer work.) Backup to a couple different SD cards in rotation and you are pretty safe in a small portable package.
The Ottercase suggestion looks good, though I would like to find a *tiny* little case that will hold a stack of, say, 6 SD cards, protecting them from crushing.
Get an old fashioned type "transistor radio" with analog tuning that takes D-cells, such as the GE Superadio III. It takes 6 D-cells. Put alkaline cells in there and it seems the thing will run forever. Decent speaker, plenty loud, good long distance AM reception, good FM reception. Be little frugal in your listening and it will probably last longer than your food supply--even if you stock up. We use one as our bathroom radio, we play it loud to hear in the shower, and I think the last set of batteries lasted well over a year.
It also runs on AC. Amazon sells it (though from other retailers).
Say some car is stolen. Does that mean every car's locks should be changed every 90-days?
A password should be changed when there is reason to believe it has been compromised. Also, passwords should never be reused across different circumstances. And they should be complex enough to not be guessable (no, "golum" is NOT a good password). But changing them every 90-days? What does that accomplish beyond making them really hard to manage, forcing people into putting them on postit notes on computer screens, or even not putting on passwords at all (see the original story here).
I suppose all physical locks in the bank should be changed every 90-days. I suppose the night drop box too, so every business that drops off cash after hours needs a new key every 90-days!
Think about security, don't just parrot. What is accomplished by each policy? What is accomplished by a 90-day password policy?
>United States Banker's Law requires all passwords >used to have a minimum level of complexity
Good.
>and for them to be changed every 90 days.
Stupid!
Passwords should be changed when there is some specific *reason* to change them.
-kb
Re:how do failures behave?
on
Basics of RAID
·
· Score: 1
On Linux...
I like software raid 1 under Linux. I use it on my basement server. On day I was burning a CD image, and that is when one of my disks died. I never knew there was a problem, the CD turned out fine, the swap on raid 1 kept running, everything was happy, and the next morning I had an e-mail waiting for me telling me to get a new disk, which I did.
The raid setup was as Redhat set up for me, but the cron script to watch for changes in/proc/mdstat and e-mailed me was homebrew.
Unless you have a lot of money, stick with pure software raid. That way all parts are generic enough that you can be sure you can get replacements. If you want to do hardware raid make sure it is good stuff. I have heard stories of the fancy raid hardware having bugs. Make sure you have good live backups and hardware spares for everything unique. Use software raid, on the other hand, and you can get spare parts retail on a Sunday.
Use raid 1 for your bootable volume, put your swap there too. If you need more space than you want to spend on raid 1, put additional disks in raid 5. I can't claim experience with raid 5, but under Linux it seems to have as good a reputation, and Linux raid 1 works great.
I can't report on any experiences with SATA, but if you can reliably boot from SATA, Linux ought to be able to do you a nice raid 1 out of that. Be aware that SATA disks and motherboards are not yet commodity enough to sell you replacements on a Sunday. Doing SATA for hotplug backups might be nice, but the sweetspot for small systems themselves is still parallel ATA.
You can do raid on top of floppies if you want--Linux is flexible. You could do encrypted raid. All pretty cool.
A specific comment: Getting your lilo or grub set up so that you can boot from either drive is a bit tricky, and if the BIOS thinks a drive is good but it only half boots it will take human intervention to tell to BIOS to boot from the other. But the good news is that is you have a decent UPS you can just keep running until there is a person there to tend to the reboot. It is possible to have a set of grub choices where if a disk is slightly functional it might run well enough to boot off the second (working disk), that way even a naive human could tend the reboot (I've setup that). One could also setup a bootable CD that then offers choices for a real boot off of either disk (I haven't done that).
If it is closed, finish closing it, don't let your routers even talk to unauthorized devices that might get plugged in (so you don't talk to the wifi box), and ring alarms if unauthorized MAC addresses appear. Certainly don't have your DHCP server issue IP addresses to just any device that gets plugged in.
If your network is open (because you secure your traffic and machines), then maybe there is no harm in having wifi on it. Install access points for your workers.
-kb, the Kent who thinks you should step back and figure out what your security goals are.
When I realized that I needed to keep all my passwords unique, I looked around and bought a Palm Zire 31 and run Keyring on it. The Zire 31 is not too expensive and I can very easily back it up with an SD card.
I also carry a Palm-based phone, but I don't trust it. It makes mysterious 10-second data calls on its own. I also don't particularly trust the Zire's software, but I keep it mostly incommunicado, so I don't have to trust it so much.
-kb, the Kent who says: "Never reuse passwords, write down passwords (encrypted if you can), and password expiration is silly."
There is another important point: Do NOT reuse passwords.
If you follow that rule you can quickly collect a *lot* passwords.
In my copy of Jochen Hoenicke's Keyring I have over 100 entries, and some of those entries have multiple passwords behind them. The worst case is my current job where I have a couple dozen passwords. Most of my frequent used passwords I remember, but every day or so I need to look up a password. Or an account number, I keep those in Keyring too.
Maybe you can remember hundreds of passwords, but it is a burden for many of us.
Yes. That's why I don't keep my passwords on my Palm-based phone (the Samsung i330 makes mysterious 10-second data calls on its own when not roaming), I keep my passwords incommunicado on an inexpensive Zire 31.
I don't trust the Palm OS, but I don't need to if I don't give it any connections to the outside world.
I've been told to remove completely non-electronic ear plugs during take-off (or was it landing?). The idea is in an emergency, when chaos is generally winning, they want to be able to shout that the front exits are on fire, so go out the rear exit--and they want you to be able to hear so you don't lumber in the wrong direction and block the aisle.
Correct. And the FAA doesn't particularly object to your use of a phone on a plane. However, the FCC objects because cell phones at high altitude mess with the cell phone systems.
Cell phones work on the idea of frequency reuse as your phone talks to one cell tower just a block or so away and many other people elsewhere in the city can also be talking using the same bandwidth. However, if you use your cell phone at 30,000 feet you will prevent cell systems in several *states* from reusing that frequency. Why will the talked about future cellphone use on planes work? By having a low powered cell site *on* the plane, your cell phone will turn its transmit power all the way down and it will not reach the ground. (And by charging really high roaming fees.)
Yes, airlines do stupid things and have many stupid rules, but these electronics rules are not completely stupid.
-kb, the Kent who is less worried about adhoc 802.11b networks on a plane.
1. Many kinds of radio receivers create a local "intermediate
frequence" (IF) version of the received signal at a much lower
frequency because it is easier for circuitry to deal with those low
frequencies. Unfortunately, this IF signal leaks out, and those
frequencies are close to those used for navigation. The FAA,
reasonably, objects to that.
2. Cellphones are based on the idea of short range communications
(from your phone to the celltower you could likely see if you knew
where to look) allowing the bandwidth you are using to be reused
many times in one city. When you turn on your phone in a plane at
high altitude, your phone (being far from any cell site) turns up
to full transmit power, and blankets several *states* worth of
territory. A lot of frequency reuse can't happen when you do that.
The FCC, reasonably, objects to this. (How can cellphones inside a
plane soon be allowed? By having a small cellsite inside the
plane, instructing phones on the plane to turn their transmit power
to the lowest setting.)
3. General purpose conservatism. A powerful transmitter (ham radio
anyone?) can also mess with lots of nearby electronics. Given all
of the confusion over what kind of electronics some device might
be, and given how pissed off you would be if your plane were
plummeting to earth because a bad decision, being conservative
might be OK, even with you.
This doesn't mean silly things don't happen. I was once (long ago) told I couldn't listen to my CD player on a plane. The airline uniformed backhaul "expert" told me that the CD player had a "laser!", and it could interfere with the plane. Nonsense. I expressed disbelief, suggesting that the laser was safely inside...but the expert didn't buy it and he had authority over me so I shut it off. However, just because he was completely wrong in his argument doesn't mean that every airline safety rule (air in the tires?, gas in the tank?, sober pilot at the wheel?, no shootouts happening on the plane?) is silly.
Historically, there are two kinds of random number generators. Pseudo random number generators (PRNGs) and hardware random number generators.
The PRNGs started out terrible and ended up being, essentially, cryptography. Supply them with a good (and unknown!) seed, and they produce excellent output.
The "true" RNGs are, indeed, random, but frequently have biases (like the purported coin that might land 51% of the time on the starting face--it has a bias, but it is otherwise a valid random number source), these RNGs will need some post processing to clean up these biases.
But you don't really want to use either of them.
Rather, a modern RNG uses a hybrid "entropy pool" model. The pool is the unknown seed, and is used to feed a PRNG algorithm. If the pool starts out unknown, the PRNG algorithm will produce good output. On the other end, a hardware entropy source is used to mix the pool in on going basis. Go ahead and feed biased coin tosses into the pool, the PRGN algorithm will remove any biases.
Where can you get such an RNG? The Linux/dev/urandom works really well. Feed your favorite entropy sources into/dev/urandom, pull as much random data as you want out of/dev/urandom. I think BSD has a similar feature.
Religious note:/dev/random will block when it computes it is out of entropy,/dev/urandom will continue producing output. Some will say you must use/dev/random, others will point out that the entropy estimation is really hard to do, and/dev/random will block at the wrong time and open you up to a denial of service risk. I say use/dev/urandom, but make up your own mind.
Wow! I thought of that about 5-years ago, thought it was really cool, but didn't have occasion to make any use of the idea. Where did you get it? (And do you have implementation details worked out?)
-kb, the Kent who doesn't have any need to steal satelite bandwidth, but who thinks it is a really cool idea.
1) You didn't read about the guy who can fool finger print scanners with simple kitchen ingredients, a scanner, and Photoshop? Too 'phisticated for you? Ok...
2) You didn't hear about they guy with the fancy new car that requires his finger to start it? Well, the bad guys took his finger and his car. I wonder whether he has enough money to buy 9 more cars.
You say you want to use the Sony HVRZ1U. Looking at the specs, I suggest it is a bad idea, particularly when you are considering post production issues.
The HVRZ1U is 1080i only. Interlace scanning was a really cool hack from the analogue age, but in the digital age it is a terrible hack. You want progressive scanning. Particularly if you hope to release on film, you want progressive scanning.
If you acquire your footage progressive you can later interlace it if you have to, but if you acquire interlaced you can never get good progressive footage out of it.
The big "1080" number might be attractive, but being interlaced it is really more like 540. Look for a progressive scanned camera if you possibly can. I think some progressive cameras run at slower frame rates, but 25 frame per second camera works really well if you want to go to 24fps film. Even if you go to video, you will get more of a film look.
That is just for conventional editing that only consists of cuts. Do anything slightly interesting (all that stuff that digital editing makes so easy) and your post production software is going to go to considerable effort to try to deinterlace. Make it easier, get better results, don't use interlace in the first place.
Interlace: A once clever hack that should not be perpetuated!
I know it isn't what you are asking for, but the little Micro-Tech tool made by http://www.swisstechtools.com/ is really neat. It is really small, small enough to go in your pocket or on a keyring without geeking up. It is a small pliers, slotted screwdriver, phillips screwdriver, wire cutter, and small shears. The newer Micro-Plus models even have very little slotted and phillips screwdrivers.
Really impressive is that the thing is dang well made: the various articulating joints are stronger than I am, and the driver bits stay sharp and square.
Yes, it is no Leatherman, but anyone who is interested in a Leatherman probably *also* wants one of these.
The Securid and Cryptocard tokens are a cool way to make a system a lot more secure, but they have their downsides: High cost, and they become cumbersome if there are multiple instances to carry around.
I have a poor man's alternative that accomplishes a lot of their benefits. A Securid/cryptocard that never changes! Seriously, login with three factors:
* Who you are (username)
* something you know (a not terribly secure password)
* something you have (long written "user code")
This way knowing who the person is (or his/er user name) isn't sufficient, knowing the password is sufficient. And knowing both isn't sufficient--you also need to have the user's wallet or purse where the user code is stored. But finding the wallet or purse alone isn't sufficient because the (short enough to remember) password isn't written down.
It is just as good as the Securid/Cryptocard except it doesn't change. Not changing means that keyboard sniffers are still a risk, but a written card is way cheap to produce and rather compact to carry around.
Too bad there isn't a PAM module available to implement this.
I get *SO* pissed at these password fascists, particularly when their rules reduce my password security.
I use secure, easy to type, and easy remember passwords (see http://ask.slashdot.org/comments.pl?sid=1323 27&cid =11054456 for details on that).
I never reuse passwords except in a few rare circumstances (on different Linux computers I personally control I reuse some passwords).
To keep track of all those passwords I bought a (relatively inexpensive) Palm Zire 31. On it I run Gnu Keyring (gnukeyring.sourceforge.net). I have one significantly secure password that I then use to encrypt all my other passwords. I backup this Palm using an SD card. I also back up to via IR to my Linux notebook where there is a client that can decrypt the data.
I also have a Palm-based phone (Samsung i330) that can run Gnu Keyring--but I don't trust it. It makes mysterious 10-second data calls that bother a paranoid such as me. Yes, I don't have any good reason to trust the Zire 31 either, but I keep it nearly incommunicado, I don't need to trust it so much.
Slashdot Mirror
$10,000 is a lot. Maybe make real but effectively no-op customizations to each legit copy so each is unique, including a banner that says whose copy it is. If it later shows up stolen you know whom to sue. Add some phone-home statistics and you know how much to sue them for. Do a little runtime checking on the visible ID banner to make hard to remove.
The pointed to Phishing IQ Test is, at least to my ideas, bogus.
I identify phishing e-mail by looking at headers, link URLs, etc.
The test e-mails were screen shots where URLs were dead and headers were missing.
-kb
> The problem is, is that if you allow people to choose any password
> they want, many will choose a short, easy to guess password.
A good password needs to have some significant randomness in it and
people are really bad judges of randomness. Even some pretty nerdly
folks can be really näive on this.
> I guess if they don't have to write it down, then it's more secure
> than a 20 character password which they do write down, but it is
> still very insecure.
What's wrong with writing down a password? Honestly, what is so wrong
with it? Yes, the proverbial postit note with the password stuck on
the edge of the monitor provides nearly* no security for a foe who is
sitting front of the computer, but the monitor is probably in your
home (where you store other valuable things), or in your office (where
a stranger walking in might be noticed by a coworker). The recent
scary innovation is that the bad guy who guesses that your password is
"Frodo" might be anywhere in the world where there is an internet
connection, which is a lot bigger than the small space in front of
your desk.
To have good security one has to stop and consider what the problem
is. What are you trying to protect, from whom, for how long?
Take the person with the password "jumbo-joker-basil" (a password used
for only one purpose) written on a piece of paper in his wallet, and
compare him with the person who uses a Really Good Password like
"Oog3gear" in many places but doesn't write it down. Which is better?
The jumbo-joker-basil password that gets written down is probably more
secure. The risk of someone stealing the wallet, knowing the
significance of jumbo-joker-basil, being interested in doing something
with it, and actually doing something about it before the person with
the lost wallet can get the password changed, is limited. On the
other side, the chances that someone who *is* interested in passwords
manages to compromise some other account that also uses the Oog3gear,
is very real, and when it happens, unlike the stolen wallet example,
the authorized user probably won't know the password has been stolen
and won't know to quickly change it. Writing down a password, if it
makes it possible to not reuse passwords, is almost always a worthy
tradeoff--particularly if it can be "written down" encrypted in a PDA
with something like the free Palm application "Keyring".
As for the two example passwords above, disregarding whether they are
reused or written down, which is more secure? The one with the most
entropy in it. Which is that? "jumbo-joker-basil"
"Oog3gear" is a pretty weak password. It is probably OK if your foe
can only try guessing passwords at a slow rate, but if your foe gets a
chance to brute force it quickly (i.e., if used for cryptography) it
is terrible!
This password was generated by pwgen in its default mode. In this
mode it produces passwords that are:
- Exactly 8 characters long,
- Have exactly one capital letter,
- Have exactly one numerical digit, and
- Are pretty easily pronounceable for an english speaker.
Because of the redundancy in english-like words, and because of the
other constraints on pwgen output, the number of possible outputs from
pwgen is not as large as one might first guess.
But the real killer for pwgen is that by default it spits out a whole
screen of suggestions and a human gets to pick one "at random". I
have not seen a scientific study on how subjects pick from this list,
but *my* tendency is to pick an easy to remember item, one that
includes a real english word, one with repetition, one that is
capitalized in a language-like way. The result is that the universe of passwords
actually chosen from pwgen output are likely a small, relatively
predictable, set. I once estimated that the number of bits of entopy
in a typical pw
I bought a PHR-250CC from Newegg (I think it was). I also bought a 2.5" drive that installed rather easily. (You need a very small phillips screw driver and you need to slide it together with the correct edge going into the correct slot.)
It has both USB 2.0 and 1394 jacks. It comes with a heavy USB cable that will power it off my notebook, but it also comes with a second USB-to-power connector cable for computers that put off less power. It also comes with a heavy 1394 cable that presumably will power it if you have a 6-pin Firewire jack.
It works great with my Linux machine, I get 27 MB/s on it. I haven't tried the 1394, but at least some of the time this model is marketed under the Macally name, so I bet it works fine with a Macintosh.
The drive is mostly metal. I don't coddle it, but it seems to stand up well. I'd buy another.
-kb
Good advice.
You can also use GNU keyring to encrypt important bits, and if you do an entire backup of your palm to the card you can put the card in any Palm you can get your hands on, and the GNU keyring software will be there too, ready to go.
Also, if you get a big SD card you can also use a computer to copy data onto it that the Palm doesn't necessarily know about. (Do the Palm backup first, note the directory structure, don't disturb it with your computer work.) Backup to a couple different SD cards in rotation and you are pretty safe in a small portable package.
The Ottercase suggestion looks good, though I would like to find a *tiny* little case that will hold a stack of, say, 6 SD cards, protecting them from crushing.
-kb
Get an old fashioned type "transistor radio" with analog tuning that takes D-cells, such as the GE Superadio III. It takes 6 D-cells. Put alkaline cells in there and it seems the thing will run forever. Decent speaker, plenty loud, good long distance AM reception, good FM reception. Be little frugal in your listening and it will probably last longer than your food supply--even if you stock up. We use one as our bathroom radio, we play it loud to hear in the shower, and I think the last set of batteries lasted well over a year.
It also runs on AC. Amazon sells it (though from other retailers).
-kb
What is the connection?
Say some car is stolen. Does that mean every car's locks should be changed every 90-days?
A password should be changed when there is reason to believe it has been compromised. Also, passwords should never be reused across different circumstances. And they should be complex enough to not be guessable (no, "golum" is NOT a good password). But changing them every 90-days? What does that accomplish beyond making them really hard to manage, forcing people into putting them on postit notes on computer screens, or even not putting on passwords at all (see the original story here).
I suppose all physical locks in the bank should be changed every 90-days. I suppose the night drop box too, so every business that drops off cash after hours needs a new key every 90-days!
Think about security, don't just parrot. What is accomplished by each policy? What is accomplished by a 90-day password policy?
-kb
>United States Banker's Law requires all passwords
>used to have a minimum level of complexity
Good.
>and for them to be changed every 90 days.
Stupid!
Passwords should be changed when there is some specific *reason* to change them.
-kb
On Linux...
/proc/mdstat and e-mailed me was homebrew.
I like software raid 1 under Linux. I use it on my basement server. On day I was burning a CD image, and that is when one of my disks died. I never knew there was a problem, the CD turned out fine, the swap on raid 1 kept running, everything was happy, and the next morning I had an e-mail waiting for me telling me to get a new disk, which I did.
The raid setup was as Redhat set up for me, but the cron script to watch for changes in
Unless you have a lot of money, stick with pure software raid. That way all parts are generic enough that you can be sure you can get replacements. If you want to do hardware raid make sure it is good stuff. I have heard stories of the fancy raid hardware having bugs. Make sure you have good live backups and hardware spares for everything unique. Use software raid, on the other hand, and you can get spare parts retail on a Sunday.
Use raid 1 for your bootable volume, put your swap there too. If you need more space than you want to spend on raid 1, put additional disks in raid 5. I can't claim experience with raid 5, but under Linux it seems to have as good a reputation, and Linux raid 1 works great.
I can't report on any experiences with SATA, but if you can reliably boot from SATA, Linux ought to be able to do you a nice raid 1 out of that. Be aware that SATA disks and motherboards are not yet commodity enough to sell you replacements on a Sunday. Doing SATA for hotplug backups might be nice, but the sweetspot for small systems themselves is still parallel ATA.
You can do raid on top of floppies if you want--Linux is flexible. You could do encrypted raid. All pretty cool.
A specific comment: Getting your lilo or grub set up so that you can boot from either drive is a bit tricky, and if the BIOS thinks a drive is good but it only half boots it will take human intervention to tell to BIOS to boot from the other. But the good news is that is you have a decent UPS you can just keep running until there is a person there to tend to the reboot. It is possible to have a set of grub choices where if a disk is slightly functional it might run well enough to boot off the second (working disk), that way even a naive human could tend the reboot (I've setup that). One could also setup a bootable CD that then offers choices for a real boot off of either disk (I haven't done that).
-kb
Do you have a closed network or an open network?
If it is closed, finish closing it, don't let your routers even talk to unauthorized devices that might get plugged in (so you don't talk to the wifi box), and ring alarms if unauthorized MAC addresses appear. Certainly don't have your DHCP server issue IP addresses to just any device that gets plugged in.
If your network is open (because you secure your traffic and machines), then maybe there is no harm in having wifi on it. Install access points for your workers.
-kb, the Kent who thinks you should step back and figure out what your security goals are.
>try and not drive one day a week
Don't drive to work at all. Find a job & live where you can take public transportation to work.
-kb, the Kent who does drive on weekends.
When I realized that I needed to keep all my passwords unique, I looked around and bought a Palm Zire 31 and run Keyring on it. The Zire 31 is not too expensive and I can very easily back it up with an SD card.
I also carry a Palm-based phone, but I don't trust it. It makes mysterious 10-second data calls on its own. I also don't particularly trust the Zire's software, but I keep it mostly incommunicado, so I don't have to trust it so much.
-kb, the Kent who says: "Never reuse passwords, write down passwords (encrypted if you can), and password expiration is silly."
There is another important point: Do NOT reuse passwords.
If you follow that rule you can quickly collect a *lot* passwords.
In my copy of Jochen Hoenicke's Keyring I have over 100 entries, and some of those entries have multiple passwords behind them. The worst case is my current job where I have a couple dozen passwords. Most of my frequent used passwords I remember, but every day or so I need to look up a password. Or an account number, I keep those in Keyring too.
Maybe you can remember hundreds of passwords, but it is a burden for many of us.
-kb
Yes. That's why I don't keep my passwords on my Palm-based phone (the Samsung i330 makes mysterious 10-second data calls on its own when not roaming), I keep my passwords incommunicado on an inexpensive Zire 31.
I don't trust the Palm OS, but I don't need to if I don't give it any connections to the outside world.
-kb, the Kent who also keeps beam receive off.
I do the same thing on a Zire 31, advantage being I can easily backup the encrypted database on SD cards.
-kb, the Kent who doesn't see any mention of an SD slot on Palm's Zire 21 page.
I've been told to remove completely non-electronic ear plugs during take-off (or was it landing?). The idea is in an emergency, when chaos is generally winning, they want to be able to shout that the front exits are on fire, so go out the rear exit--and they want you to be able to hear so you don't lumber in the wrong direction and block the aisle.
-kb
"phones dont do anything to planes"
Correct. And the FAA doesn't particularly object to your use of a
phone on a plane. However, the FCC objects because cell phones at
high altitude mess with the cell phone systems.
Cell phones work on the idea of frequency reuse as your phone talks to
one cell tower just a block or so away and many other people elsewhere
in the city can also be talking using the same bandwidth. However, if
you use your cell phone at 30,000 feet you will prevent cell systems
in several *states* from reusing that frequency. Why will the talked
about future cellphone use on planes work? By having a low powered
cell site *on* the plane, your cell phone will turn its transmit power
all the way down and it will not reach the ground. (And by charging
really high roaming fees.)
Yes, airlines do stupid things and have many stupid rules, but these
electronics rules are not completely stupid.
-kb, the Kent who is less worried about adhoc 802.11b networks on a
plane.
Three things.
1. Many kinds of radio receivers create a local "intermediate
frequence" (IF) version of the received signal at a much lower
frequency because it is easier for circuitry to deal with those low
frequencies. Unfortunately, this IF signal leaks out, and those
frequencies are close to those used for navigation. The FAA,
reasonably, objects to that.
2. Cellphones are based on the idea of short range communications
(from your phone to the celltower you could likely see if you knew
where to look) allowing the bandwidth you are using to be reused
many times in one city. When you turn on your phone in a plane at
high altitude, your phone (being far from any cell site) turns up
to full transmit power, and blankets several *states* worth of
territory. A lot of frequency reuse can't happen when you do that.
The FCC, reasonably, objects to this. (How can cellphones inside a
plane soon be allowed? By having a small cellsite inside the
plane, instructing phones on the plane to turn their transmit power
to the lowest setting.)
3. General purpose conservatism. A powerful transmitter (ham radio
anyone?) can also mess with lots of nearby electronics. Given all
of the confusion over what kind of electronics some device might
be, and given how pissed off you would be if your plane were
plummeting to earth because a bad decision, being conservative
might be OK, even with you.
This doesn't mean silly things don't happen. I was once (long ago)
told I couldn't listen to my CD player on a plane. The airline
uniformed backhaul "expert" told me that the CD player had a "laser!",
and it could interfere with the plane. Nonsense. I expressed
disbelief, suggesting that the laser was safely inside...but the
expert didn't buy it and he had authority over me so I shut it off.
However, just because he was completely wrong in his argument doesn't
mean that every airline safety rule (air in the tires?, gas in the
tank?, sober pilot at the wheel?, no shootouts happening on the
plane?) is silly.
-kb
Historically, there are two kinds of random number generators. Pseudo
/dev/urandom works really /dev/urandom, pull as /dev/urandom. I think BSD has a
/dev/random will block when it computes it is out of /dev/urandom will continue producing output. Some will say /dev/random, others will point out that the entropy /dev/random will block at the /dev/urandom, but make up your own mind.
random number generators (PRNGs) and hardware random number
generators.
The PRNGs started out terrible and ended up being, essentially,
cryptography. Supply them with a good (and unknown!) seed, and they
produce excellent output.
The "true" RNGs are, indeed, random, but frequently have biases (like
the purported coin that might land 51% of the time on the starting
face--it has a bias, but it is otherwise a valid random number
source), these RNGs will need some post processing to clean up these
biases.
But you don't really want to use either of them.
Rather, a modern RNG uses a hybrid "entropy pool" model. The pool is
the unknown seed, and is used to feed a PRNG algorithm. If the pool
starts out unknown, the PRNG algorithm will produce good output. On
the other end, a hardware entropy source is used to mix the pool in on
going basis. Go ahead and feed biased coin tosses into the pool, the
PRGN algorithm will remove any biases.
Where can you get such an RNG? The Linux
well. Feed your favorite entropy sources into
much random data as you want out of
similar feature.
Religious note:
entropy,
you must use
estimation is really hard to do, and
wrong time and open you up to a denial of service risk. I say use
-kb
Wow! I thought of that about 5-years ago, thought it was really cool, but didn't have occasion to make any use of the idea. Where did you get it? (And do you have implementation details worked out?)
-kb, the Kent who doesn't have any need to steal satelite bandwidth, but who thinks it is a really cool idea.
Can't steal your finger print? Bah!
1) You didn't read about the guy who can fool finger print scanners with simple kitchen ingredients, a scanner, and Photoshop? Too 'phisticated for you? Ok...
2) You didn't hear about they guy with the fancy new car that requires his finger to start it? Well, the bad guys took his finger and his car. I wonder whether he has enough money to buy 9 more cars.
-kb
You say you want to use the Sony HVRZ1U. Looking at the specs, I
suggest it is a bad idea, particularly when you are considering post
production issues.
The HVRZ1U is 1080i only. Interlace scanning was a really cool hack
from the analogue age, but in the digital age it is a terrible hack.
You want progressive scanning. Particularly if you hope to release on
film, you want progressive scanning.
If you acquire your footage progressive you can later interlace it if
you have to, but if you acquire interlaced you can never get good
progressive footage out of it.
The big "1080" number might be attractive, but being interlaced it is
really more like 540. Look for a progressive scanned camera if you
possibly can. I think some progressive cameras run at slower frame
rates, but 25 frame per second camera works really well if you want to
go to 24fps film. Even if you go to video, you will get more of a
film look.
That is just for conventional editing that only consists of cuts. Do
anything slightly interesting (all that stuff that digital editing
makes so easy) and your post production software is going to go to
considerable effort to try to deinterlace. Make it easier, get better
results, don't use interlace in the first place.
Interlace: A once clever hack that should not be perpetuated!
-kb
I know it isn't what you are asking for, but the little Micro-Tech
tool made by http://www.swisstechtools.com/ is really neat. It is
really small, small enough to go in your pocket or on a keyring
without geeking up. It is a small pliers, slotted screwdriver,
phillips screwdriver, wire cutter, and small shears. The newer
Micro-Plus models even have very little slotted and phillips
screwdrivers.
Really impressive is that the thing is dang well made: the various
articulating joints are stronger than I am, and the driver bits stay
sharp and square.
Yes, it is no Leatherman, but anyone who is interested in a Leatherman
probably *also* wants one of these.
-kb
The Securid and Cryptocard tokens are a cool way to make a system a
lot more secure, but they have their downsides: High cost, and they
become cumbersome if there are multiple instances to carry around.
I have a poor man's alternative that accomplishes a lot of their
benefits. A Securid/cryptocard that never changes! Seriously, login
with three factors:
* Who you are (username)
* something you know (a not terribly secure password)
* something you have (long written "user code")
This way knowing who the person is (or his/er user name) isn't
sufficient, knowing the password is sufficient. And knowing both
isn't sufficient--you also need to have the user's wallet or purse
where the user code is stored. But finding the wallet or purse alone
isn't sufficient because the (short enough to remember) password isn't
written down.
It is just as good as the Securid/Cryptocard except it doesn't change.
Not changing means that keyboard sniffers are still a risk, but a
written card is way cheap to produce and rather compact to carry
around.
Too bad there isn't a PAM module available to implement this.
-kb
I get *SO* pissed at these password fascists, particularly when their
3 27&cid =11054456 for
rules reduce my password security.
I use secure, easy to type, and easy remember passwords (see
http://ask.slashdot.org/comments.pl?sid=132
details on that).
I never reuse passwords except in a few rare circumstances (on
different Linux computers I personally control I reuse some
passwords).
To keep track of all those passwords I bought a (relatively
inexpensive) Palm Zire 31. On it I run Gnu Keyring
(gnukeyring.sourceforge.net). I have one significantly secure
password that I then use to encrypt all my other passwords. I backup
this Palm using an SD card. I also back up to via IR to my Linux
notebook where there is a client that can decrypt the data.
I also have a Palm-based phone (Samsung i330) that can run Gnu
Keyring--but I don't trust it. It makes mysterious 10-second data
calls that bother a paranoid such as me. Yes, I don't have any good
reason to trust the Zire 31 either, but I keep it nearly incommunicado, I
don't need to trust it so much.
I recommend Gnu Keyring.
-kb