These tools are fine for personal use - but not easily adapted to corporate use e.g. PCI DSS. Mandatory requirements for PCI DSS include key management under dual control and split knowledge. As such, commercial tools still rule in the storage encryption space. And I'm no programmer, so I can't resolve these shortcomings. lyalc
So, this means ant in an encrypted volume, where the directory and node structure are not visible, you need to 1) identify where an encrypted image is, and apply this comparison algorithm to the EXACT same unencrypted image, to see if it's there.
In other words, the best that this can really do is prove is an image is is in the encrypted volume, by applying the comparison algorithm every 512/4096 bytes along the volume's byte array.
Good for providing a law enforcement case, not much for detecting evidence of a crime - unless you are stupid enough to leave the images around as unencrypted versions as as well as encrypted.
For about a year, now, I have been having to put up with their rubbish content and the 30 I spiel during the safety session on by $5 for 1 hour of watching TV is a good deal. If you don't pay up, you get a flight's worth of commercials, back to back. ad nausea. over and over
The funny thing is, you have to "opt out' of having advertising in your face for the flight duration. If they used the opt out model everywhere, then drinks and snacks would be free until you decided you did not want any more! (as is)
At least you can blank the display by turning down the brightness. And the display gets a lot cooler.
It'd be a brave coder to come forward and claim damages for copyright infringement in this case, imho. Of course, this may also require that a copyright licence accompanied the virus.
Much spyware does have a copyright licence, so reverse engineering these can be a very different story.
So what protects yours rivate key thats linked toyyour X.509 cert? Either nothing (so simply accessing your maachine=being you) or a password (so cracking a password is needed before someone can masquerade as you)
This sort of idea is shortsighted and achieves nothing positive for security.
THis seems silly to me. In other words, the sole protection of the network and all applications you have access to is the password on your workstation/logon account. Break one machine, access all your apps and networks, in your name. I wouldn't want that liability on my shoulders.
Actually, modestly simple, technically. The hard part is the business rules and profit. For example, your payment and your 'contract of sale" is notionally with PayPal, NOT the machine operator nor the product manufacturer. PayPal has all the warranty, liability and customer issues. A good deal for machine operator and the product manufacturer, but not so good for consumers..... Because there is another mouth the feed in the retailing chain who wants to be paid, the price for the product goes up, so we all as consumers lose due to higher prices to satify a few who use this payment mechanism.
What about when you want to add or delete accounts to your on-line banking What happens when you lose you private key, and can't decrypt those important messages about your accounts and the cotracts for service (banking, deposit holding, interest etc are all contracted servies)? And then a tax audit, bankruptcy, or civil suit that requires legal discovery?
Without evidence to defend yourself, life is sooooo much mre difficult. These sorts of reasons are why PGP, gpg and S/MIME never work in corporate environments - the problems are worse than the benefits.
The UK experience is that moving to PIN has removed about 40% of the fraud that occured under signature-based authentication, according to recent reports.
Implementing virtual terminals (or hardware based terminals in mobile phones et al) with a PIN to effect an legal electronic signature is simple, and doesn't need PKI or digita certificates, thus is very cheap by comparison to PKI.
Why is this surprising? The US banking industry has documented policies that permit and encourage this to occur. Get a 20th century banking system, and these incidents will stop virtually completely.
Given fraud is around 0.5% of the value of payments, this is ridiculously expensive to implement and operate - it will cost several times the level of current and (imho) future expected fraud.
For example. This is just a password controlled approach - so evey time you forget a password, get a new box, at $10-$50 per year, plus $30-$100 per incident for admin costs. Now think about how often the devices get lost, damaged, or don't work due to software compatibility problems (drivers, OS versions etc), and the true cost may exceed $100 per year, PER CUSTOMER. In US terms, thats $2B per year, just for a single solution thats only as good as a password!
Surely we techos can be smarter about these issues!
NOt clear what the goal is. If its enhanced authenticaiton, you are still stuck with single factor password authetication - it just occurs on the workstation, rather than your server with PKI.
i.e. PKI means the server always accepts valid certificates, rather tan c a single process of verifying passwords. Evenry single workstaitn becomes a difference password authentication location - and I bet not all are as reliable for this purpose as 1 server. lyal
Let me turn he question around and ask "who can install a multi billion dollar tool that is only as good as a password?" Certs and smartcards can be accessed remotely via a number of legitmate and less legitimate means. Only the user's password has any semblence of controlling the use of the private key, and hence authentication. PKI us just password authentication, performed at the remote terminal, where the user is hopefully co-located.
If the need is signing emails or intra-domain logon control, then there are better, more flexible tools tan public key.
Ummm. Virtually no PKI schemes today are a two factor mechanism. Usually, they remain a 1 password system, sometimes a 2 password system. Since there are lots of ways to remotely send data to a smartcard.USB token etc, then the password - or a biometric- remains the ONLY controlling factor.
So, its just a card with a password, and a chunk of crypto that said the password was right or wrong - e.g. by oututting a a transaction wrapped in other crypto. No one ever explains why this is better than an ID/account number and password?
In some countries, Debit is better than credit. -there are strong laws about consumer and to a lesser degree, merchant protection. - Strong security, via 4 or 6 digit PINs with enforced 3 fails=locked card - ubiqutious access that equals or betters Credit card access - costs are lower for consumer and merchant (hence banks don't like it is as much) - rules are country specific, not managed by committees inside Visa/Amex/MasterCard - PIN = electronic signature (in those countries that use strong, non ANSI X.9-like debit protocols)
Downside = no 'over the phone' use of dedit facilities, due to the security problems of PIN disclosure
What about cetain forms of remote support, IT admins who install software on behalf of users ( both company IT staff, and 'friends who help out' etc) and Windows auto-update et al? Do I have to get the user to read and approve each EULA before I install?
Why is any of this different to commercial softwar development" Generally, one person controls the signing key(s), either directly, or via authority over those who do have access to the key. What's so different about open source projects? Only that there is not always an organisaiton to blame, sometimes it's an identified individual. State that liability is accepted (or not) by the signing individual in the code package and documentation, and the problem is then on of recipient beware (I'm sure there is a caveat emptor-like term for this) Lyal
err - read the EFT Code of Conduct that applies as law in Australia (available from ASIC or ASX). Banks DO have liability here regardless of whether they provide sftware or not - anything they implicitly approve of for electronically accessing personal bank accounts puts liability on banks under the above document in most fraud situations.
Sorry, In Australia, banks can't reject claims so easily. The EFT Code of Conduct, which has the effect of federal law, applies here. In effect, this document says that the bank has to respond within a certain time frame (28 days, I think) and that 'any method implicitly or explicitly approved of by the bank is covered' and goes on to say that provided the consumer (i.e. not a business customer) did not deliberately disclose their password, then unauthorised transactions are to be reimbursed by the bank. It's arguable that requiring AV/malware is an 'approved' method, but no one has yet resolved the final boundaries of the above EFT Code of Conduct.
Why will a site trust Auth_Service X or Y, or any other? If PKI or Passport are anything to go by, Auth_Service providers will charge the earth, disclaim all responsibility, and force their business practices onto you your customers and business partners. Decentralised or not, Single Sign-on models like this are pointless unless the Auth_Server provider is financialy committed to getting it right - every time.
Slashdot Mirror
These tools are fine for personal use - but not easily adapted to corporate use e.g. PCI DSS. Mandatory requirements for PCI DSS include key management under dual control and split knowledge.
As such, commercial tools still rule in the storage encryption space.
And I'm no programmer, so I can't resolve these shortcomings.
lyalc
So, this means ant in an encrypted volume, where the directory and node structure are not visible, you need to 1) identify where an encrypted image is, and apply this comparison algorithm to the EXACT same unencrypted image, to see if it's there.
In other words, the best that this can really do is prove is an image is is in the encrypted volume, by applying the comparison algorithm every 512/4096 bytes along the volume's byte array.
Good for providing a law enforcement case, not much for detecting evidence of a crime - unless you are stupid enough to leave the images around as unencrypted versions as as well as encrypted.
lyalc
For about a year, now, I have been having to put up with their rubbish content and the 30
I spiel during the safety session on by $5 for 1 hour of watching TV is a good deal.
If you don't pay up, you get a flight's worth of commercials, back to back.
ad nausea.
over and over
The funny thing is, you have to "opt out' of having advertising in your face for the flight duration.
If they used the opt out model everywhere, then drinks and snacks would be free until you decided you did not want any more! (as is)
At least you can blank the display by turning down the brightness. And the display gets a lot cooler.
lyalc
It'd be a brave coder to come forward and claim damages for copyright infringement in this case, imho.
Of course, this may also require that a copyright licence accompanied the virus.
Much spyware does have a copyright licence, so reverse engineering these can be a very different story.
Lyal
So what protects yours rivate key thats linked toyyour X.509 cert?
Either nothing (so simply accessing your maachine=being you) or a password (so cracking a password is needed before someone can masquerade as you)
This sort of idea is shortsighted and achieves nothing positive for security.
Lyal
THis seems silly to me.
In other words, the sole protection of the network and all applications you have access to is the password on your workstation/logon account.
Break one machine, access all your apps and networks, in your name.
I wouldn't want that liability on my shoulders.
Lyal
Actually, modestly simple, technically.
The hard part is the business rules and profit.
For example, your payment and your 'contract of sale" is notionally with PayPal, NOT the machine operator nor the product manufacturer.
PayPal has all the warranty, liability and customer issues.
A good deal for machine operator and the product manufacturer, but not so good for consumers.....
Because there is another mouth the feed in the retailing chain who wants to be paid, the price for the product goes up, so we all as consumers lose due to higher prices to satify a few who use this payment mechanism.
What about when you want to add or delete accounts to your on-line banking
What happens when you lose you private key, and can't decrypt those important messages about your accounts and the cotracts for service (banking, deposit holding, interest etc are all contracted servies)? And then a tax audit, bankruptcy, or civil suit that requires legal discovery?
Without evidence to defend yourself, life is sooooo much mre difficult.
These sorts of reasons are why PGP, gpg and S/MIME never work in corporate environments - the problems are worse than the benefits.
Lyal
The UK experience is that moving to PIN has removed about 40% of the fraud that occured under signature-based authentication, according to recent reports.
Implementing virtual terminals (or hardware based terminals in mobile phones et al) with a PIN to effect an legal electronic signature is simple, and doesn't need PKI or digita certificates, thus is very cheap by comparison to PKI.
Why is this surprising?
The US banking industry has documented policies that permit and encourage this to occur.
Get a 20th century banking system, and these incidents will stop virtually completely.
Given fraud is around 0.5% of the value of payments, this is ridiculously expensive to implement and operate - it will cost several times the level of current and (imho) future expected fraud.
For example.
This is just a password controlled approach - so evey time you forget a password, get a new box, at $10-$50 per year, plus $30-$100 per incident for admin costs.
Now think about how often the devices get lost, damaged, or don't work due to software compatibility problems (drivers, OS versions etc), and the true cost may exceed $100 per year, PER CUSTOMER.
In US terms, thats $2B per year, just for a single solution thats only as good as a password!
Surely we techos can be smarter about these issues!
Here's another S/MIME question:
Once the recipient's private key (used for decryption) is lost, how does the COMPANY get its data back?
Lyal
NOt clear what the goal is.
If its enhanced authenticaiton, you are still stuck with single factor password authetication - it just occurs on the workstation, rather than your server with PKI.
i.e. PKI means the server always accepts valid certificates, rather tan c a single process of verifying passwords. Evenry single workstaitn becomes a difference password authentication location - and I bet not all are as reliable for this purpose as 1 server.
lyal
Let me turn he question around and ask "who can install a multi billion dollar tool that is only as good as a password?"
Certs and smartcards can be accessed remotely via a number of legitmate and less legitimate means.
Only the user's password has any semblence of controlling the use of the private key, and hence authentication. PKI us just password authentication, performed at the remote terminal, where the user is hopefully co-located.
If the need is signing emails or intra-domain logon control, then there are better, more flexible tools tan public key.
Google S/MIME
Ummm.
Virtually no PKI schemes today are a two factor mechanism.
Usually, they remain a 1 password system, sometimes a 2 password system.
Since there are lots of ways to remotely send data to a smartcard.USB token etc, then the password - or a biometric- remains the ONLY controlling factor.
Lyal
So, its just a card with a password, and a chunk of crypto that said the password was right or wrong - e.g. by oututting a a transaction wrapped in other crypto.
No one ever explains why this is better than an ID/account number and password?
Lyal
In some countries, Debit is better than credit.
-there are strong laws about consumer and to a lesser degree, merchant protection.
- Strong security, via 4 or 6 digit PINs with enforced 3 fails=locked card
- ubiqutious access that equals or betters Credit card access
- costs are lower for consumer and merchant (hence banks don't like it is as much)
- rules are country specific, not managed by committees inside Visa/Amex/MasterCard
- PIN = electronic signature (in those countries that use strong, non ANSI X.9-like debit protocols)
Downside = no 'over the phone' use of dedit facilities, due to the security problems of PIN disclosure
Neither PCI, AIS or SDP would have prevented these incidents.
Simply these are people problems, not addressed by document reviews that these standards call for.
What about cetain forms of remote support, IT admins who install software on behalf of users ( both company IT staff, and 'friends who help out' etc) and Windows auto-update et al?
Do I have to get the user to read and approve each EULA before I install?
Why is any of this different to commercial softwar development"
Generally, one person controls the signing key(s), either directly, or via authority over those who do have access to the key.
What's so different about open source projects?
Only that there is not always an organisaiton to blame, sometimes it's an identified individual.
State that liability is accepted (or not) by the signing individual in the code package and documentation, and the problem is then on of recipient beware (I'm sure there is a caveat emptor-like term for this)
Lyal
err - read the EFT Code of Conduct that applies as law in Australia (available from ASIC or ASX).
Banks DO have liability here regardless of whether they provide sftware or not - anything they implicitly approve of for electronically accessing personal bank accounts puts liability on banks under the above document in most fraud situations.
Lyal
Sorry, In Australia, banks can't reject claims so easily.
The EFT Code of Conduct, which has the effect of federal law, applies here.
In effect, this document says that the bank has to respond within a certain time frame (28 days, I think) and that 'any method implicitly or explicitly approved of by the bank is covered' and goes on to say that provided the consumer (i.e. not a business customer) did not deliberately disclose their password, then unauthorised transactions are to be reimbursed by the bank.
It's arguable that requiring AV/malware is an 'approved' method, but no one has yet resolved the final boundaries of the above EFT Code of Conduct.
Lyal
Isn't that like saying a worm is only a worm/malware in the presence of vulnerable software or OS?
Lyal
Why will a site trust Auth_Service X or Y, or any other?
If PKI or Passport are anything to go by, Auth_Service providers will charge the earth, disclaim all responsibility, and force their business practices onto you your customers and business partners.
Decentralised or not, Single Sign-on models like this are pointless unless the Auth_Server provider is financialy committed to getting it right - every time.