The solution is to never write cleartext data to the drive. If all writes (including swap) are always encrypted, and the encryption key is maintained in a secure manner, then residual data is meaningless.
If the data on the disk looks like a random series of zeros and ones, then you don't need to have an emergency overwrite process to nuke your disks, you can just "forget" your encryption key and claim the data was overwritten:)
This claim is bogus, and is a claim about the public key RSA algorithm, which has nothing to do with the actual subject of the article, the RSA "SecurID" hardware token.
The currently shipping RSA hardware tokens are based on AES, and even the older tokens are not known to be broken.
There have only been two documented theoretical attacks against the SecurID tokens -- an attack against the software RSA token emulator (the article is about the hardware token only) and a theoretical attack against older RSA tokens, which would only be effective against certain "seed" values and only after observing hundreds of the displayed token values over at least several weeks. When the latter research was published, RSA changed how they generated "seed" values to ensure that this attack would not function in the real world.
Since the tokens are not renewable, expire in 3-5 years, any older "weak" tokens will eventually be retired.
Seems to me that you can easily store a list of passwords and challenges on a small device with an lcd-screen. Since OPIE passwords do not depend on the time or date, you can just use a list, no? You just have to renew it after some time (e.g. 100 logins) but that's not a major problem.
I guess the idea has always been that the token device always just stores your seed value XOR'd with your PIN, so somebody who walks off with your token doesn't have access to any useful stored data. Soring pre-calculated respinses goes against this concept.
Another interesting alternative would be for the token to have a one-level look-ahead cache. After you use a tokencode, the device pre-calculates the next resppnse code and stores it encrypted against your PIN, then goes to sleep.
This cuts down on the risk and exposure, requires less storage memory, and gives faster startup time than if the response is only calculated at the moment you need it.
A friend who is studying in sweeden at the moment has basically a scratch card with 40 numbers on it, when she goes to login she enters her username, password and then scratches off a panel to get a 8 digit numeric token to enter.
When she has used about 30/40 the bank send out a new card.
Its a whole lot cheaper than handing out SecureID devices to customers and i'm really suprised that most banks dont have this already, its the size of a credit card and fits nicely in a walle
Now this sounds like something that can easily be implemented in Open Source.
The software should not be difficult to implement (just a simple variation on RMD160 S/Key to produce short alphanumeric keys?) and the hardware to print your own scratch off cards runs maybe a couple of grand at most.
While this approach might not be a good solution for other places where SecurID is deployed (I use my token at work 8-20 times a day), it makes a lot of sense for online banking where people might authenticate once a week/month, and don't mind waiting for the post to get their next set of one time passwords.
I've always thought that what we really need is devices like this with an LCD display that tells you what, exactly, you are signing.
I agree 100%. Too bad somebody like RSA is probably already sitting on the patent.
I'd like to see something that can do the same for digital signatures on non-financial documents. Something like a security-hardened tablet PC so you can review and sign a contract in a secure digital form?
. ..
The device I described: The LCD screen displays the question "Authorize payment of $59 to Acme Co.? Yes/No". No charge can go through without your device approving it. You only need to trust that your device will ask you to confirm any charge. And you can trust it because the manufacturer knows that if it screws up, they'll get their pants sued off.
Sounds like Citibank's VAN taken a step or three further.
There are a couple of new tokens coming on the market which offer both a LCD display and also USB connection, but they only seem to have one line of maybe 6-8 alphanumerics, and just a single push button (for response-only auth token use). Not quite enough output or inputs to implement something like what you describe.
Anyone else that does RSA Ace administration can confirm this for me, but you should be able to use the same RSA token for multiple accounts. That means ONE token for access to your bank, credit union, online stock broker, whatever.
Yes, this is technically possible.
There is one serious flaw in this approach -- because the
ACE/SecurID tokens use a single embedded shared-secret "seed", any organization which has the key (seed file) for your token can in theory emulate that token perfectly, spoofing the randomly generated number (Source code has been published to demonstrate this for older SecurID soft tokens, see above URL). The seed would always be the same for all places you auth to, only the PIN would differ.
So your credit union could, if they can keyboard-sniff the PIN, spoof a login as you into your bank or stock broker.
RSA tokens come with accompanying software (or a key) which is used to import the token to the ACE authentication server. With that software you can load one token into multiple RSA servers. With a token and its software, you could send your accompanying token software to Bank A and to Bank B, they load your RSA token and you can then use the same token to authenticate to both accounts. As an added measure of security, the usernames do not have to be the same, nor does the accompanying PIN for each account.
Earlier this year RSA changed how they ship the seed media, so this is no longer easily possible.
Now when you order a batch of tokens, RSA asks for the license info from the server you will use the tokens with, and ships the seed media encoded so the seeds can only be loaded onto that one specific server.
The software I use now for importation imports batches of Ace tokens that we distribute to customers, but I am sure it wouldn't be difficult to supply one "key" per token.
I have steadily been seeing more and more phishing schemes in my email and they look more and more legit every day. Two factor authentication needs to be implemented soon before more and more people lose their money to scammers.
I would be more than happy to pay $50-$100 for a token and software that I could use to authenticate to all my online financial services.
I'm not sure that I would just a single token that authenticates across multiple entities. How can I know that a hacker at my credit union isn't using my credentials to empty out my brokerage account?
The good news is that AOL and other businesses are offering tokens to users for around ten bucks a pop, where we pay around fifty bucks (we buy batches of two thousand tokens to even get the price this low).
Around 5 years ago I was looking for a way to have a secure-id sort of solution without having to buy the proprietary software and hardware without any success.
The first "open" standard for authentication tokens was part of ANSI X9.9, and was broken (and subsequently retracted) back in 1999. The old X9.9 algorithm is still available as an optional authentication method in several hardware tokens offered by competitors of RSA/SecurID.
Have you looked at GNU SASL (Simple Authentication and Security Layer framework)?
I even looked into building my own (I know a little about microcontrollers for the hardware device portion) but was not able to come up with any suitable algorithm. It seems like the security of our Linux systems and other systems which require authentication could really benefit from something like this.
An open source implementation of the SecurID time-based authentication algorithm is not possible because RSA holds several patents covering their whole time-based authentication scheme.
The closest solution in the open-source world might be OPIE (formerly S/Key). OpenBSD and other operating systems include S/Key support in the base OS.
There are OPIE calculators for MD4/MD5 in Java and for most handhelds, but it is tough to find a SHA-1 or RMD-160 implemention, and I have yet to run across any dedicated hardware device that does nothing but handle OPIE authentication.
With the uncertainty about SHA-1, You might plan to implement only RMD-160 (160 bit Ripe Message Digest). Tokens would need a bit more CPU power to handle a few hundred rounds, but at least there is a good chance that RMD will still be a viable hash, long after SHA-1 falls.
Challenge-response isn't inherently more secure than an auto-updating number based on time. Both are basically implementations of a pseudo-random function. With the auto-updater, the current time is essentially the challenge. And not having to type/scan in an explicit challenge is a lot more usable
Good point. There are also a number of vendors who have response-only tokens, less expensive competitors to RSA.
Also, the old X9.9 based Secure Net Key (SNK, aka Axent Defender) implementation of challenge-response was fatally flawed. There are still versions of this floating around, and it is an optional mode for the VASCO, Safeword, and CryptoCard tokens.
How long before someone finds a fast way of factoring large numbers and we're all screwed?
There's no direct relationship between the SecurID tokens sold by RSA and the old RSA algorithm.
Actually, the latest generation of SecurID tokens use AES, however RSA still ships backlogs of the older tokens which are built around a proprietary hash.
Like most other response-only tokens, the authentication is based not on large primes like public-key authentication but rather on a shared secret (one embedded in the token, the other stored on the authentication server.
Much work has been done towards cryptanalysis of response-only tokens, and a well-designed authentication system is very difficult to break blindly, just from observation of a few response pairs. There have been potentially successful attacks proposed against the old SecurID tokens due to a "vanishing differential" problem with certain seed values, but no proof of concept against that has succeeded, and the new AES tokens should not be vulnerable. More on this is available from the SecurID Users group.
As a counter-example, the old X9.9 challenge-response authentication system was based on DES encryption, and was not well-designed, was fatally flawed. Observation of a handful of challenges and responses cojuld allow an attacker to determine the seed value and compromise the authenticator.
"RSA keys" in the title is a bit misleading.. It makes it sounds like a full crypto implementation, using smart cards and all the capabilities that implies. Confusing the RSA crypto algorithm, with the SecurID card, a product made by the company RSA.
A common mistake. Most of the articles I've seen lately on the subject have not mentioned either "RSA" or "SecurID", just talking about "devices" or "tokens" or perhaps "two factor authentication".
SecurID is just a clunky authentication system using a hardware token to display numbers used for the authentication (although, they do also offer software tokens. there is nothing magical about the hardware)
Why not go to a modern smart card system? It can store full certificates, and tie directly into really strong security/crypto. Tie the smart card / cert into the autentication of your system, and into IPSec, SSL, etc.
SecurID offers only the authentication piece, based on a completely closed algorithm.
The SecurID hardware token has two primary advantages over smart cards, and most other authentication tokens:
No additional hardware or software or drivers are needed to authenticate. Just the token and (optionalyl) a user selected PIN.
While smart cards have their place, they are not so great for handing out to remote users. For example, does anybody actually use the card reader that was distributed in the American Express "Blue" promotion a few years back?
Isn't the NYT sold at a loss? I don't think that you correctly analysed the economic consequence of a bunch of nerds just buying the NYT, cuting out the Firefox ad and trashing the rest.
It's a newspaper, not an X-box. The NYT isn't going to print any extra copies on "Firefox day", any unsold copies of any day's edition are themselves a loss, sent back to the distrbutor to be
recycled into cat litter.
Generally the wholesale price of a newspaper just barely covers the cost of paper, ink, and distribution. Advertisers (like the firefox project) cover the costs of content and infrastructure -- newsgathering, layout, printing plants, plus a healthy profit margin for the publisher.
Re:Time sync all your computers
on
Computer Forensics
·
· Score: 4, Insightful
There is no (good) exuse for not at least NTP'ing all your servers.
There used to be a good excuse -- recurring root holes in all common NTP implementations.
Solaris is the only reason anyone buys a Sparc box. Selling Sparc boxes is Sun's main form of income.
Not the only reason -- some people would purchase low-end Sparc64 servers to run OpenBSD/Sparc64, due to security and stability requirements (e.g. the the N^X instruction calls in the Sparc processor, OpenBoot, etc).
This includes Netra T1, Sunfire V100/V120, and also systems based on the AXi and Netra CP lines of OEM motherboards.
These days most of those people are purchasing dual processor AMD64 systems instead.
They sell both really solid machines (400SC?) and utter shitpiece machines (600SC). Sometimes you get a good deal and sometimes the stupid thing just crashes when you put 2 or more PCI cards in it.
Their only saving grace is that once you figure out the right machine for your needs, they usually keep selling them for a while so you can buy another one when you need it.
The issue I have with Dell is that they will change out a couple of the chipsets on a machine, but keep selling them under the exact same model number, and just ship updated Windows drivers for the new chips.
This is fine, assuming you are running windows on the machine in question.
Rather than wait for Dell to make up their mind about AMD chips, we are switching to Opteron-powered Sunfire servers.
I asked about SMP for Sparc32 (I have a quad SS20!) but there was no take on that. SMP for Sparc64 maybe coming..
The new darling of the OpenBSD developers is AMD64, we can expect development on that platform to take priority, with Sparc and Sparc64 being somewhat neglected.
As much as I hate to say this, we may never see OpenBSD offering SMP for Sparc platforms.
Obsolyte has a great archive of Sun hardware pictures.
http://www.obsolyte.com/sunPICS/
The SparcStation 20 is my favorite example, though several later products (in particular, the E450) exhibit similar design sensibilities.
One thing to watch for is if you are putting the Original (Windows) installation back onto the Laptop. Most OEM Restore Disks check your hardware, not just type/brand/model, but EXACT component. They "Tatoo" the HDD so the Restore knows what to do.
You may find that you are unable to Restore your OS back onto the new drive.
Only solutions to this are to put a new OS on it (Retail Windows, *nix, other...) or to phone tech-support...
I've had a 100% success rate with Windows 2000 in using Symantec "Ghost" to image the original drive to the new, larger drive.
Connect both drives to single PC (I use a docking station with an internal IDE controller and a cheap "laptop IDE to standard IDE" cable).
Using a MS-DOS boot floppy, boot into DOS and run "ghost.exe"
When copying from the source drive to the new drive, you can choose to enlarge both FAT and NTFS partitions to make better use of the larger drive, or you can leave some or all of the extra space unpartitioned (handy for dual-boot into Unix)
Make sure that you copy all partitions, some laptops store setup and configuration information in a small extra partition.
Depending on the IDE drive and adaptor, imaging can take a while. Start the process, then go out for lunch... a long lunch.
You can keep the original drive around as a backup, or take it apart and play with the neat glass disk platters and tiny powerful magnets.
I just went through this on three laptops (upgrading them to new 40Gb drives). Toshiba Tecra.
The one thing that tripped me up was the screws. There are six screws holding the drive inside the carrier, all are held in with something like loctite (not exactly, but close), and all are philips.
Four of these tiny screws came out easily, but on all but one of the machines, exactly two of the screws would not come out, usually the head would get stripped and I ended up using needle-nose or side-cutters to get a grip on the side of the head and break the loctite.
So my recommendation is to have the right screw drivers, and also a good assortment of other small tools in case you need to force something.
The author of ipf (Darren Reed) is regularly on the openbsd mailing lists, and quite often it's just gripe. This whole issue has become quite personal, jugding from the posts.
Yeah, what's up with that? His contributions vary from sardonic to the merely sarcastic. Darren is clearly a bright guy, his criticism could be constructive if he wanted.
Back on topic, this post by Darren is particularly amusing:
To: deraadt@cvs.openbsd.org (Theo de Raadt) Subject: Re: OpenBSD 3.6 From: Darren Reed <avalon@caligula.anu.edu.au> Date: Wed, 29 Sep 2004 12:14:38 +1000 (Australia/ACT) Cc: misc@openbsd.org
Hey wow, I just got told that I get a mention in the lyrics:) Thanks:)
That's almost enough to tempt me into buying my 1st ever CD:)
Not everyone gets immortalised (for better or worse) into song so thanks:)
Under no circumstances get a gun. It is a stupid precaution that only serves to increase your risk substantially. Killing someone is a tough thing, and your more likely to get shot with your own weapon (or get sued by someone you shoot) than you are to successfully defend your home.
Why must you spread propaganda and lies?
You are not more likely to get shot with your own weapon (unless you count suicides) than to successfully defend your home. Statisically, the most likely outcome is that grandma never has to use the weapon in self-defense, dies peacefully in her sleep a couple of years later, and wills the shotgun to a grateful heir.
1. Motion sensing lights at proper heights placed for full coverage of important areas.
Motion sensing lights -- the only good suggestion in the bunch.
2. Motion detector webcam with pre-programmed scanning capabilities (the wireless Toshiba unit is superb http://www.toshiba.com/taisisd/netcam/index.htm)
An 802.11 webcam? WTF?
While this is a good geek answer, a webcam is not good security. It is possible to set up good video surveillance with recording, but this is not the way to do so.
3. Alarm system securing all major entranced points, and if you can afford it all the screens as well
Forget this. Get a real professionally installed monitored alarm system, with active+passive motion sensing and zoned sensors. If there are areas of the house which grandma never uses, she can enable not only the perimeter sensor, but also the motion sensor inside that zone.
Because it's all about keeping grandma safe and alive, not keeping her geek grandson busy spying on grandma with a Toshiba webcam.
Sorry for being so blunt, but unless she's able to park the car in a secure area such as a garage, there's basically nothing that you can do beyond a car alarm to deter a break in.
Too true. Crooks are deterred by well-lighted areas and cameras, anything that can get them caught (by cops or a car owner with a baseball bat). A very obvious, sensitive, and loud car alarm might help, until they realize that nobody responds to car alarms anymore.
You can get a car alarm which will page you, but I don't see what a grandma is likely to do when her car pages her at 3AM...
This is a primary reason why auto insurance costs less in areas with lower crime rates -- there's not much you can do to deter a petty theif doing a simple smash and grab on a car.
I agree. So the solution is to move to an area with lower crime rates, and park her car in a secure area (garage) with surveillance.
Slashdot Mirror
The solution is to never write cleartext data to the drive. If all writes (including swap) are always encrypted, and the encryption key is maintained in a secure manner, then residual data is meaningless.
If the data on the disk looks like a random series of zeros and ones, then you don't need to have an emergency overwrite process to nuke your disks, you can just "forget" your encryption key and claim the data was overwritten :)
This claim is bogus, and is a claim about the public key RSA algorithm, which has nothing to do with the actual subject of the article, the RSA "SecurID" hardware token.
The currently shipping RSA hardware tokens are based on AES, and even the older tokens are not known to be broken.
There have only been two documented theoretical attacks against the SecurID tokens -- an attack against the software RSA token emulator (the article is about the hardware token only) and a theoretical attack against older RSA tokens, which would only be effective against certain "seed" values and only after observing hundreds of the displayed token values over at least several weeks. When the latter research was published, RSA changed how they generated "seed" values to ensure that this attack would not function in the real world.
Since the tokens are not renewable, expire in 3-5 years, any older "weak" tokens will eventually be retired.
Another interesting alternative would be for the token to have a one-level look-ahead cache. After you use a tokencode, the device pre-calculates the next resppnse code and stores it encrypted against your PIN, then goes to sleep.
This cuts down on the risk and exposure, requires less storage memory, and gives faster startup time than if the response is only calculated at the moment you need it.
The software should not be difficult to implement (just a simple variation on RMD160 S/Key to produce short alphanumeric keys?) and the hardware to print your own scratch off cards runs maybe a couple of grand at most.
While this approach might not be a good solution for other places where SecurID is deployed (I use my token at work 8-20 times a day), it makes a lot of sense for online banking where people might authenticate once a week/month, and don't mind waiting for the post to get their next set of one time passwords.
I'd like to see something that can do the same for digital signatures on non-financial documents. Something like a security-hardened tablet PC so you can review and sign a contract in a secure digital form?
Sounds like Citibank's VAN taken a step or three further.There are a couple of new tokens coming on the market which offer both a LCD display and also USB connection, but they only seem to have one line of maybe 6-8 alphanumerics, and just a single push button (for response-only auth token use). Not quite enough output or inputs to implement something like what you describe.
There is one serious flaw in this approach -- because the ACE/SecurID tokens use a single embedded shared-secret "seed", any organization which has the key (seed file) for your token can in theory emulate that token perfectly, spoofing the randomly generated number (Source code has been published to demonstrate this for older SecurID soft tokens, see above URL). The seed would always be the same for all places you auth to, only the PIN would differ.
So your credit union could, if they can keyboard-sniff the PIN, spoof a login as you into your bank or stock broker.
Earlier this year RSA changed how they ship the seed media, so this is no longer easily possible.Now when you order a batch of tokens, RSA asks for the license info from the server you will use the tokens with, and ships the seed media encoded so the seeds can only be loaded onto that one specific server.
I'm not sure that I would just a single token that authenticates across multiple entities. How can I know that a hacker at my credit union isn't using my credentials to empty out my brokerage account?The good news is that AOL and other businesses are offering tokens to users for around ten bucks a pop, where we pay around fifty bucks (we buy batches of two thousand tokens to even get the price this low).
Have you looked at GNU SASL (Simple Authentication and Security Layer framework)?
An open source implementation of the SecurID time-based authentication algorithm is not possible because RSA holds several patents covering their whole time-based authentication scheme. The closest solution in the open-source world might be OPIE (formerly S/Key). OpenBSD and other operating systems include S/Key support in the base OS.There are OPIE calculators for MD4/MD5 in Java and for most handhelds, but it is tough to find a SHA-1 or RMD-160 implemention, and I have yet to run across any dedicated hardware device that does nothing but handle OPIE authentication. With the uncertainty about SHA-1, You might plan to implement only RMD-160 (160 bit Ripe Message Digest). Tokens would need a bit more CPU power to handle a few hundred rounds, but at least there is a good chance that RMD will still be a viable hash, long after SHA-1 falls.
Also, the old X9.9 based Secure Net Key (SNK, aka Axent Defender) implementation of challenge-response was fatally flawed. There are still versions of this floating around, and it is an optional mode for the VASCO, Safeword, and CryptoCard tokens.
more detail here.
Like most other response-only tokens, the authentication is based not on large primes like public-key authentication but rather on a shared secret (one embedded in the token, the other stored on the authentication server.
Much work has been done towards cryptanalysis of response-only tokens, and a well-designed authentication system is very difficult to break blindly, just from observation of a few response pairs. There have been potentially successful attacks proposed against the old SecurID tokens due to a "vanishing differential" problem with certain seed values, but no proof of concept against that has succeeded, and the new AES tokens should not be vulnerable. More on this is available from the SecurID Users group.
As a counter-example, the old X9.9 challenge-response authentication system was based on DES encryption, and was not well-designed, was fatally flawed. Observation of a handful of challenges and responses cojuld allow an attacker to determine the seed value and compromise the authenticator.
- RSA has patents on time-based tokens, this allows for a simple sealed hardware token without any buttons.
- No additional hardware or software or drivers are needed to authenticate. Just the token and (optionalyl) a user selected PIN.
While smart cards have their place, they are not so great for handing out to remote users. For example, does anybody actually use the card reader that was distributed in the American Express "Blue" promotion a few years back?Generally the wholesale price of a newspaper just barely covers the cost of paper, ink, and distribution. Advertisers (like the firefox project) cover the costs of content and infrastructure -- newsgathering, layout, printing plants, plus a healthy profit margin for the publisher.
With OpenNTPD, this is no longer a valid excuse.
It's nice to see a traffic signal enhancement that will actually make driving more efficient and direct rather than the opposite.
This includes Netra T1, Sunfire V100/V120, and also systems based on the AXi and Netra CP lines of OEM motherboards.
These days most of those people are purchasing dual processor AMD64 systems instead.
This is fine, assuming you are running windows on the machine in question.
Rather than wait for Dell to make up their mind about AMD chips, we are switching to Opteron-powered Sunfire servers.
I'm confused, what does raw fish on rice have to do with data security?
http://www.obsolyte.com/sunPICS/ The SparcStation 20 is my favorite example, though several later products (in particular, the E450) exhibit similar design sensibilities.
You can keep the original drive around as a backup, or take it apart and play with the neat glass disk platters and tiny powerful magnets.
The one thing that tripped me up was the screws. There are six screws holding the drive inside the carrier, all are held in with something like loctite (not exactly, but close), and all are philips.
Four of these tiny screws came out easily, but on all but one of the machines, exactly two of the screws would not come out, usually the head would get stripped and I ended up using needle-nose or side-cutters to get a grip on the side of the head and break the loctite.
So my recommendation is to have the right screw drivers, and also a good assortment of other small tools in case you need to force something.
Back on topic, this post by Darren is particularly amusing:
Although it's just one of many changes, it receives an inordinate amount of attention.
I'm tempted to make my next machine a dual-processor AMD64 system just to play with all of the new features in 3.6
The comments seemed to lean towards the Soekris and similar GEODE products, and the VIA EPIA.
You are not more likely to get shot with your own weapon (unless you count suicides) than to successfully defend your home. Statisically, the most likely outcome is that grandma never has to use the weapon in self-defense, dies peacefully in her sleep a couple of years later, and wills the shotgun to a grateful heir.
Motion sensing lights -- the only good suggestion in the bunch. An 802.11 webcam? WTF?While this is a good geek answer, a webcam is not good security. It is possible to set up good video surveillance with recording, but this is not the way to do so. Forget this. Get a real professionally installed monitored alarm system, with active+passive motion sensing and zoned sensors. If there are areas of the house which grandma never uses, she can enable not only the perimeter sensor, but also the motion sensor inside that zone.
Because it's all about keeping grandma safe and alive, not keeping her geek grandson busy spying on grandma with a Toshiba webcam.
You can get a car alarm which will page you, but I don't see what a grandma is likely to do when her car pages her at 3AM...
I agree. So the solution is to move to an area with lower crime rates, and park her car in a secure area (garage) with surveillance.