Because they are transmitted bright and clear all over the place? Whitelisting the authorised MAC addresses assumes that you do not trust the encryption (or there is none). If you assume the encryption is broken, you assume anyone can listen to the network and intercept any and all MAC addresses being transmitted (in [nearly?] every single packet).
Nothing prevents you from creating one account per game, and selling said account when tired of said game.
Re:Thwarted by properly designed online banking
on
Real-Time Keyloggers
·
· Score: 2, Insightful
Actually, my point was that other vendors provide tokens that require a PIN to be input into the device, rather than to the server. The device can be locked if an incorrect PIN is entered, etc.
Also, I never intended to say that Authentication Servers implementing SecurID weren't able to counter replay-attacks (this is a base functionality), I was merely stating that it didn't use event-counters to calculate the OTP. Other vendors provide this functionnality, and this enhances security, as instead of having only a time-based OTP (that is, having an OTP that changes every x seconds), you can also include event-based information (an event counter is basically just a number that gets incremented every time the OTP is generated), and thus the server is able to know how many times an OTP has been generated (this also removes the issue you were talking of, a new OTP can be generated on-demand, even if the time-window hasn't changed, the OTP will be different).
The added advantage is that one can monitor how many tries a user needs to successfully login. Also, devices can get "unsynchronised" if too many OTPs are generated (the server only calculates that many OTPs).
Another thing is that some vendors will have the device update its key after every OTP generation (hence the reason the event counter is useful, as to know how many times the key has been updated). This is not something RSA is able to do. They keep yelling to their customers that AES is absolutely required on these devices, and in their case it is. However, other vendors get away with using much lighter encryption keys (3DES, for example), because the key is a brand new one after every single OTP, the OTP is only valid for a few minutes, whereas 3DES still requires 10 hours or so to be cracked.
No. The probability is still the same, but the number of times it is applied increases.
Re:Thwarted by properly designed online banking
on
Real-Time Keyloggers
·
· Score: 2, Informative
That would depend on the version of the token, I guess. There is not just one universal version. Some have keypads, others don't.
Re:Thwarted by properly designed online banking
on
Real-Time Keyloggers
·
· Score: 3, Insightful
A good solution (read as "implementation") would consist of a challenge that the user can verify corresponds to the transaction he wishes to do. Four first digits of the Challenge are the four last digits of the sum. Six last digits of the Challenge are the six first digits of the target bank account. Etc.
Nobody can expect good security if the user doesn't watch out and double checks what's happening. The attack you're talking of could very well be done to a poor old lady paying her bills for the month in front of her bank manager. Just slip a bill she shouldn't pay: if neither she or the bank pay attention, the money will be stolen.
Even though I work in this field, and I'd love to come up with a solution that fixes all the issues, I just don't believe it. There will always be monkeys reading through tons of transactions, trying to spot the one that doesn't belong, and you will always having your credit card company calling you when suddenly there's $5k flying through some casino 800 miles from your residence.
There is no ultimate security when it comes to banking apps, especially when you give end-users, and thus end-computers (which can and will be infected/modified/hacked in all ways imaginable or not) access to your application, you can't trust it. The only thing we can try to do is mitigate the risk for the general population, and hope we can filter out the few hacks. If you don't spot it, just pay the bill. The amount of money you lose that way will always be less than trying to fund impossible research that may yield nothing at all.
Re:Thwarted by properly designed online banking
on
Real-Time Keyloggers
·
· Score: 5, Informative
Disclaimer: I work for one of RSA's competitors in this domain.
The article focuses on RSA's SecurID, but one of the main drawbacks of RSA's SecurID is that it is only time based. Other companies also use event-counters, which means that you can't actually replay the attack.
The parent is right (and I should now, I deploy these solutions), most serious banks will use OTPs (One Time Passwords) for the initial log-on, but then require Challenge-Responses to sign the transactions (website provides a challenge, which can be a completely random number, or based on a number of variables: amount, target account, etc; this challenge is provided to the token (stupidly named "gadget" in the summary), and it spits out a response.) This can be verified by the server.
OTPs have always had this flaw, and this really isn't any news. I've heard of attacks were real-time keyloggers would interrupt the network connection (wifi, ethernet, whatever) on a software/OS level temporarily (I assume by refreshing the DHCP bumf) as to allow the attacker to use the OTP.
However, this can be easily thwarted.
Any good Authentication Server will provide the option to use seeded authentication, and even though this doesn't apply to OTPs (most OTP algorithms actually include clock counter (and event counter if it is implemented, not RSA's case) related information in the OTP, hence the whole OTP is required for authentication), it does apply to Memorable Data. For example, 2nd and 8th character of your secret passcode. Or for example, even better: multiply the 4th digit of your OTP with the 6th digit of your secret passcode. (OTP still required to be input completely). Yeah sure, given sufficient time, the attacker should be able to know what your passcode is, but heck, that's going to require quite some effort.
Wikipedia has a bit of a section about the MITM attacks vulnerabilities of OTPs (even though it is right in SecurID's article, it doesn't apply to them alone, but to the concept as a whole). The main issue, however, with RSA's implementation isn't necessarily the MITM attack, but quite simply, stealing the token. It doesn't have a PIN code, heck, it even just shows the code the whole time (last one I checked did this), and I could read the number right off my friend's keychain.
Also, let us not forget that a one-time attack (which again, shouldn't be much of an issue if banks have a good solution that requires CRs for each transaction) on an account really isn't a big deal. It's a One-Time Password. It's only valid once. After he's visited the account, and seen the balance, that's about as far as he's going to go.
Nothing to see here, please move along. If anything, this is just going to drive our business a bit.
How much did you spend on your razors? I pay less than pennies for a shave and probably have a closer shave than most people who use the gillette uber-maximum-fusion stealth hyperium razors.
The first-ever video advertisement will be published in a traditional paper magazine â" Entertainment Weekly â" in September
No. The first-ever video advertisement was published a long time ago. Also, no traditional paper magazine has video. Hence the reason they are traditional.
Try again.
"The first-ever video advertisement to be published in a paper magazine will..."
Has this ever happened to you?
You work very horde on a paper for English clash
And then get a very glow raid (like a D or even a D=)
and all because you are the word's liverwurst spoiler.
Proofreading your peppers is a matter of the the utmost impotence.
This is a problem that affects manly, manly students.
I myself was such a bed spiller once upon a term
that my English teacher in my sophomoric year,
Mrs. Myth, said I would never get into a good colleague.
And that's all I wanted, just to get into a good colleague.
Not just anal community colleague,
because I wouldn't be happy at anal community colleague.
I needed a place that would offer me intellectual simulation,
I really need to be challenged, challenged dentally.
I know this makes me sound like a stereo,
but I really wanted to go to an ivory legal collegue.
So I needed to improvement
or gone would be my dream of going to Harvard, Jail, or Prison
(in Prison, New Jersey).
So I got myself a spell checker
and figured I was on Sleazy Street.
But there are several missed aches
that a spell chukker can't can't catch catch.
For instant, if you accidentally leave a word
your spell exchequer won't put it in you.
And God for billing purposes only
you should have serial problems with Tori Spelling
your spell Chekhov might replace a word
with one you had absolutely no detention of using.
Because what do you want it to douch?
It only does what you tell it to douche.
You're the one with your hand on the mouth going clit, clit, clit.
It just goes to show you how embargo
one careless clit of the mouth can be.
Which reminds me of this one time during my Junior Mint.
The teacher read my entire paper on A Sale of Two Titties
out loud to all of my assmates.
I'm not joking, I'm totally cereal.
It was the most humidifying experience of my life,
being laughed at pubically.
So do yourself a flavor and follow these two Pisces of advice:
One: There is no prostitute for careful editing.
And three: When it comes to proofreading,
the red penis your friend.
Just get on your bike or lift dumbells. Killing your body by removing a required nutrient isn't a diet, it's stupid. Probably as much as vegans.
Simple equation: energy in == energy consumed. If that is not the case, you're doing it wrong. You obviously have enough self-discipline to prevent yourself from eating things you decide, so why not have the self-discipline to do the same using a healthy diet and some exercise?
Disclaimer: I work for a company that specialises in these kind of deployments, however, they do not endorse anything I am about to say, and I am doing so as an individual. All the information in here is public knowledge.
A few points first:
- A CA doesn't only create encryption certificate. It can create a variety of certificates, including Windows Logon, Signing certificates, etc. It all depends on the Certificate Policies that are configured on the CA.
- We have no information the CA was indeed issuing SSL certificates. More likely, they were encryption certificates used to decrypt the patient's medical files. According to this link the card also contains a signing certificate.
- There are a lot of different types of HSMs. Some will encrypt their data (Security World, for nCipher) on a remote filesystem (RFS, especially in the case of netHSMs) that can be on any machine. As long as you have the Administrator Card Set (or a quorum of those, m of n cards required to perform specific tasks), you can reload the Security World, reload the keys, and are good to go. Other HSMs provide in-hardware "protection" of the keys, such as SafeNet HSMs, and the data in these can be backed up through hardware tokens (which are just very secure PCMCIA cards). HSMs usually have built-in hardware protections so you can't break it open or something, without destruction of the data.
- It is stupid for both the service provider and the customer to have gone without backups of the Root CA. What is the point of replicating your production environment in a reference/test environment, if you're not going to do a full replication?
- As each company looks like an idiot, they will try to blame each other, and they already do. Quite typical. The Service Provider is saying "we did what the customer wanted", and the customer says "The service provider was taking care of the tests". They are both stupid and wrong.
- Smartcards are protected by master keys. When the smartcard manufacturer creates the cards, he initialises them, usually with a "Manufacturer Key". This key is known by anyone who ever worked in the industry. In a normal setup, when the customer (the company issuing the cards to their users) gets the cards, during the card personalisation, they swap the Master Keys using their own keys. This is probably the most important part. Without those Master Keys, nobody can access the card's applets, or perform administrative actions on the card. Not even the owner with the PIN. It is very likely that for a solution of this size, the card manufacturer (according to this link, GnD and Gemalto are part of the project. GnD will supply their 80k card) were using the customer's Master Keys initially, so that the key swapping wasn't needed (or simply, the cards wouldn't be usable anywhere else).
If in the same accident, the Master Keys for the smartcards were lost, then they can effectively throw away all the cards that were created in that batch, as nobody will be able to access the applets on the cards, thus, nobody will be able to update the certificates, or even erase the cards. This doesn't mean the certificates are dead, the certificates can still be used on a daily basis without any issue, but considering the CA will not be able to publish its CRL (which needs to be published every x hours/days, and has an expiry threshold), the certificate chain would become untrusted after some time (probably a few years, considering the Root CA should NOT be connected, but rather locked in a safe, and never need to publish its CRL for the length of the certificate's lifetime), and only then will problems start to arise.
I do hope for the sake of the companies involved in this project that they didn't ask the manufacturers to produce the test batches with the customer's Master Keys and that the Master Key was lost,
Asynchronous requests aren't that difficult to implement. Most XML-based request-response languages (SOAP, SPML, SAML) have at least a notion of asynch transmission.
Worried about privacy? Just PKI encrypt + sign the whole request so you know where it came from, and who it is destined to, and you don't need the age old "sessions" anymore. Sessions only make sense in a system that relies on synchronous communications.
Now of course, we can't ensure delivery, but then again, I don't see how that would be part of the requirements when you've got aliens eating your crew, and computers refusing to open the latch.
Excepted that spreading rumors about Google is just like playing Nostradamus.
Say 5000 different things, even with 0.1% accuracy, that's still 5 items that will hit. Google is fanning out horizontally, so you're bound to hit the target at least once.
How many rumors have there been about Google or Apple?
Slashdot Mirror
Because they are transmitted bright and clear all over the place? Whitelisting the authorised MAC addresses assumes that you do not trust the encryption (or there is none). If you assume the encryption is broken, you assume anyone can listen to the network and intercept any and all MAC addresses being transmitted (in [nearly?] every single packet).
There is also a limited number of non-geeks.
I take it you've never heard of Steam?
Nothing prevents you from creating one account per game, and selling said account when tired of said game.
Actually, my point was that other vendors provide tokens that require a PIN to be input into the device, rather than to the server. The device can be locked if an incorrect PIN is entered, etc.
Also, I never intended to say that Authentication Servers implementing SecurID weren't able to counter replay-attacks (this is a base functionality), I was merely stating that it didn't use event-counters to calculate the OTP. Other vendors provide this functionnality, and this enhances security, as instead of having only a time-based OTP (that is, having an OTP that changes every x seconds), you can also include event-based information (an event counter is basically just a number that gets incremented every time the OTP is generated), and thus the server is able to know how many times an OTP has been generated (this also removes the issue you were talking of, a new OTP can be generated on-demand, even if the time-window hasn't changed, the OTP will be different).
The added advantage is that one can monitor how many tries a user needs to successfully login. Also, devices can get "unsynchronised" if too many OTPs are generated (the server only calculates that many OTPs).
Another thing is that some vendors will have the device update its key after every OTP generation (hence the reason the event counter is useful, as to know how many times the key has been updated). This is not something RSA is able to do. They keep yelling to their customers that AES is absolutely required on these devices, and in their case it is. However, other vendors get away with using much lighter encryption keys (3DES, for example), because the key is a brand new one after every single OTP, the OTP is only valid for a few minutes, whereas 3DES still requires 10 hours or so to be cracked.
No. The probability is still the same, but the number of times it is applied increases.
That would depend on the version of the token, I guess. There is not just one universal version. Some have keypads, others don't.
A good solution (read as "implementation") would consist of a challenge that the user can verify corresponds to the transaction he wishes to do. Four first digits of the Challenge are the four last digits of the sum. Six last digits of the Challenge are the six first digits of the target bank account. Etc.
Nobody can expect good security if the user doesn't watch out and double checks what's happening. The attack you're talking of could very well be done to a poor old lady paying her bills for the month in front of her bank manager. Just slip a bill she shouldn't pay: if neither she or the bank pay attention, the money will be stolen.
Even though I work in this field, and I'd love to come up with a solution that fixes all the issues, I just don't believe it. There will always be monkeys reading through tons of transactions, trying to spot the one that doesn't belong, and you will always having your credit card company calling you when suddenly there's $5k flying through some casino 800 miles from your residence.
There is no ultimate security when it comes to banking apps, especially when you give end-users, and thus end-computers (which can and will be infected/modified/hacked in all ways imaginable or not) access to your application, you can't trust it. The only thing we can try to do is mitigate the risk for the general population, and hope we can filter out the few hacks. If you don't spot it, just pay the bill. The amount of money you lose that way will always be less than trying to fund impossible research that may yield nothing at all.
Disclaimer: I work for one of RSA's competitors in this domain.
The article focuses on RSA's SecurID, but one of the main drawbacks of RSA's SecurID is that it is only time based. Other companies also use event-counters, which means that you can't actually replay the attack.
The parent is right (and I should now, I deploy these solutions), most serious banks will use OTPs (One Time Passwords) for the initial log-on, but then require Challenge-Responses to sign the transactions (website provides a challenge, which can be a completely random number, or based on a number of variables: amount, target account, etc; this challenge is provided to the token (stupidly named "gadget" in the summary), and it spits out a response.) This can be verified by the server.
OTPs have always had this flaw, and this really isn't any news. I've heard of attacks were real-time keyloggers would interrupt the network connection (wifi, ethernet, whatever) on a software/OS level temporarily (I assume by refreshing the DHCP bumf) as to allow the attacker to use the OTP.
However, this can be easily thwarted.
Any good Authentication Server will provide the option to use seeded authentication, and even though this doesn't apply to OTPs (most OTP algorithms actually include clock counter (and event counter if it is implemented, not RSA's case) related information in the OTP, hence the whole OTP is required for authentication), it does apply to Memorable Data. For example, 2nd and 8th character of your secret passcode. Or for example, even better: multiply the 4th digit of your OTP with the 6th digit of your secret passcode. (OTP still required to be input completely). Yeah sure, given sufficient time, the attacker should be able to know what your passcode is, but heck, that's going to require quite some effort.
Wikipedia has a bit of a section about the MITM attacks vulnerabilities of OTPs (even though it is right in SecurID's article, it doesn't apply to them alone, but to the concept as a whole). The main issue, however, with RSA's implementation isn't necessarily the MITM attack, but quite simply, stealing the token. It doesn't have a PIN code, heck, it even just shows the code the whole time (last one I checked did this), and I could read the number right off my friend's keychain.
Also, let us not forget that a one-time attack (which again, shouldn't be much of an issue if banks have a good solution that requires CRs for each transaction) on an account really isn't a big deal. It's a One-Time Password. It's only valid once. After he's visited the account, and seen the balance, that's about as far as he's going to go.
Nothing to see here, please move along. If anything, this is just going to drive our business a bit.
Slashdot frontpage already has a story about Twitter Developing Location-Based API
... is the structure of my chromosomes.
If it takes you half your shave to notice the blade is blunt, you're doing it wrong.
Double-edged razor. Stop the marketing.
How much did you spend on your razors? I pay less than pennies for a shave and probably have a closer shave than most people who use the gillette uber-maximum-fusion stealth hyperium razors.
No. The first-ever video advertisement was published a long time ago. Also, no traditional paper magazine has video. Hence the reason they are traditional.
Try again.
"The first-ever video advertisement to be published in a paper magazine will..."
Has this ever happened to you?
You work very horde on a paper for English clash
And then get a very glow raid (like a D or even a D=)
and all because you are the word's liverwurst spoiler.
Proofreading your peppers is a matter of the the utmost impotence.
This is a problem that affects manly, manly students.
I myself was such a bed spiller once upon a term
that my English teacher in my sophomoric year,
Mrs. Myth, said I would never get into a good colleague.
And that's all I wanted, just to get into a good colleague.
Not just anal community colleague,
because I wouldn't be happy at anal community colleague.
I needed a place that would offer me intellectual simulation,
I really need to be challenged, challenged dentally.
I know this makes me sound like a stereo,
but I really wanted to go to an ivory legal collegue.
So I needed to improvement
or gone would be my dream of going to Harvard, Jail, or Prison
(in Prison, New Jersey).
So I got myself a spell checker
and figured I was on Sleazy Street.
But there are several missed aches
that a spell chukker can't can't catch catch.
For instant, if you accidentally leave a word
your spell exchequer won't put it in you.
And God for billing purposes only
you should have serial problems with Tori Spelling
your spell Chekhov might replace a word
with one you had absolutely no detention of using.
Because what do you want it to douch?
It only does what you tell it to douche.
You're the one with your hand on the mouth going clit, clit, clit.
It just goes to show you how embargo
one careless clit of the mouth can be.
Which reminds me of this one time during my Junior Mint.
The teacher read my entire paper on A Sale of Two Titties
out loud to all of my assmates.
I'm not joking, I'm totally cereal.
It was the most humidifying experience of my life,
being laughed at pubically.
So do yourself a flavor and follow these two Pisces of advice:
One: There is no prostitute for careful editing.
And three: When it comes to proofreading,
the red penis your friend.
Taylor Mali is a genius.
Yeah, and how can a heart be hard to transplant between Man and Pig as they use the heart for pretty much everything?
Low or no-carb diets are bad.
Just get on your bike or lift dumbells. Killing your body by removing a required nutrient isn't a diet, it's stupid. Probably as much as vegans.
Simple equation: energy in == energy consumed. If that is not the case, you're doing it wrong. You obviously have enough self-discipline to prevent yourself from eating things you decide, so why not have the self-discipline to do the same using a healthy diet and some exercise?
Now that's going to make for interesting pillow talk.
The clue is in the name.
n/t
Some might have heard of The Battle of Poitier, or the Siege of Orleans, The Battle of Waterloo, or the Battle of Saratoga...
But those battles are all shadowed to be forgotten by the epicness of the Battle of Wikipedia!
Disclaimer: I work for a company that specialises in these kind of deployments, however, they do not endorse anything I am about to say, and I am doing so as an individual. All the information in here is public knowledge.
A few points first:
- A CA doesn't only create encryption certificate. It can create a variety of certificates, including Windows Logon, Signing certificates, etc. It all depends on the Certificate Policies that are configured on the CA.
- We have no information the CA was indeed issuing SSL certificates. More likely, they were encryption certificates used to decrypt the patient's medical files. According to this link the card also contains a signing certificate.
- There are a lot of different types of HSMs. Some will encrypt their data (Security World, for nCipher) on a remote filesystem (RFS, especially in the case of netHSMs) that can be on any machine. As long as you have the Administrator Card Set (or a quorum of those, m of n cards required to perform specific tasks), you can reload the Security World, reload the keys, and are good to go. Other HSMs provide in-hardware "protection" of the keys, such as SafeNet HSMs, and the data in these can be backed up through hardware tokens (which are just very secure PCMCIA cards). HSMs usually have built-in hardware protections so you can't break it open or something, without destruction of the data.
- It is stupid for both the service provider and the customer to have gone without backups of the Root CA. What is the point of replicating your production environment in a reference/test environment, if you're not going to do a full replication?
- As each company looks like an idiot, they will try to blame each other, and they already do. Quite typical. The Service Provider is saying "we did what the customer wanted", and the customer says "The service provider was taking care of the tests". They are both stupid and wrong.
- Smartcards are protected by master keys. When the smartcard manufacturer creates the cards, he initialises them, usually with a "Manufacturer Key". This key is known by anyone who ever worked in the industry. In a normal setup, when the customer (the company issuing the cards to their users) gets the cards, during the card personalisation, they swap the Master Keys using their own keys. This is probably the most important part. Without those Master Keys, nobody can access the card's applets, or perform administrative actions on the card. Not even the owner with the PIN. It is very likely that for a solution of this size, the card manufacturer (according to this link, GnD and Gemalto are part of the project. GnD will supply their 80k card) were using the customer's Master Keys initially, so that the key swapping wasn't needed (or simply, the cards wouldn't be usable anywhere else).
If in the same accident, the Master Keys for the smartcards were lost, then they can effectively throw away all the cards that were created in that batch, as nobody will be able to access the applets on the cards, thus, nobody will be able to update the certificates, or even erase the cards. This doesn't mean the certificates are dead, the certificates can still be used on a daily basis without any issue, but considering the CA will not be able to publish its CRL (which needs to be published every x hours/days, and has an expiry threshold), the certificate chain would become untrusted after some time (probably a few years, considering the Root CA should NOT be connected, but rather locked in a safe, and never need to publish its CRL for the length of the certificate's lifetime), and only then will problems start to arise.
I do hope for the sake of the companies involved in this project that they didn't ask the manufacturers to produce the test batches with the customer's Master Keys and that the Master Key was lost,
It makes me cringe.
One-Time-Passwords and Strong Authentication are the way to go.
Asynchronous requests aren't that difficult to implement. Most XML-based request-response languages (SOAP, SPML, SAML) have at least a notion of asynch transmission.
Worried about privacy? Just PKI encrypt + sign the whole request so you know where it came from, and who it is destined to, and you don't need the age old "sessions" anymore. Sessions only make sense in a system that relies on synchronous communications.
Now of course, we can't ensure delivery, but then again, I don't see how that would be part of the requirements when you've got aliens eating your crew, and computers refusing to open the latch.
Excepted that spreading rumors about Google is just like playing Nostradamus.
Say 5000 different things, even with 0.1% accuracy, that's still 5 items that will hit. Google is fanning out horizontally, so you're bound to hit the target at least once.
How many rumors have there been about Google or Apple?