Assume for a minute that the OS is doing its job. Then no, you can't install userland rootkits. You can't install background startup programs.
If the attacker has access to your session, you have lost.
No. If my session limits the attacker, then I most certainly have not lost.
If an attacker has access to your machine and you have not used disk encryption, you have lost.
But I have disk encryption. So how have I lost?
if you were willing to place money on the line I could easily write you a service in AutoIt or Powershell which scrapes all of your "secured" firefox passwords and mails them to me with nothing more required than the ability to drop a file somewhere in your user profile.
Who said Firefox was doing things any better?
I will bet money that you can't do the same to my Keepass database.
Said bad guy can dump all your session cookies, grab your history, install malicious extension to intercept all your browsing activity, or install OS user account level monitoring software
This assumes bad guy has access to an account with root/admin access. How about OS accounts that are locked down, for the exact reason of preventing these types of exploits? Obviously Chrome can run on a limited account.
It is irresponsible to rely on the underlying OS security (or insecurity) as a crutch. So what if someone has physical access? Just because they can type on a keyboard or insert a USB drive, doesn't mean they can run an exploit. What will they do, install a rootkit? What if they can't reboot the computer? What if they can't get past BIOS and full disk encryption?
Seriously... I'm getting mad just at the thought that the head of any computer security team can think in this way.
The term "catholic" means "universal" or "general". The earliest churches of Christ were catholic, not Catholic.
What those churches and followers of Christ were, and what Catholicism is today, are as different as night and day. The Catholic religion's belief system is not founded by scripture.
If using the keys is possible then extracting the keys are possible.
Using this line of thought, we should get rid of computer cryptography. After all, it's possible to crack any cryptographic system, just very unlikely.
You may not like storing keys in code... I certainly don't like it either... but sometimes the requirements are non-negotiable. What you do then is make it as secure as possible, and if obfuscation helps, then we use it.
Obfuscation can help reduce the chances of finding an exploitable route for SQL injection. If I am trying to break a complex piece of software, and the field that is susceptible to SQL injection is guarded by dozens of conditions, then it may be easier to decompile the program and attempt to find SQL strings with concatenation and then see where they are are not being sanitized.
And of course I'm not talking about building the software with a trojan/backdoor. I'm talking about a way in which an attacker gets access to your machine. At that point, the attacker still may not have root/administrator access, but may be able to read the software file in question. That's why obfuscation is important, it is another layer of obscurity in case enough real security measures are broken.
Many Christians believe Catholicism is a perversion. It certainly was back in the days of indulgences, but even today it is built on a foundation that doesn't hold up to scripture. In many cases, Catholics rally behind ideas that Jesus even rebuked (but to be fair, that can be said about several other "Christian" doctrines and about many who call themselves Christian).
Seriously, other than making personal computing become something from communist russia, what is the benefit of this?
Security. One major benefit of obfuscation is making it much more difficult to find local data store encryption keys, service endpoints, etc. It makes it harder to find bugs/exploits such as SQL injection.
Remember that not all attacks are aimed at the software in general. Many, many attacks on medical/banking/government systems are aimed at finding specific data on specific computers, and the attacker isn't running it on a VM. These attacks rely on perhaps a trojan or backdoor. The harder it is to build such an attack, the better.
A different judge would have convicted Badawi of apostasy and sentenced him to death. Remember that when you get an urge to say this judge's sentence is barbaric.
[citation needed]
I'm pretty damn sure an American judge absolutely would not.
Doubtful. Every company in the Android space is trying to dominate it. But Android is a seriously competitive market within itself.
I would agree if you proposed that Nokia may have had better sales by this point. It's up to them to decide whether to get lost in the crowd in a good market, or stand out from the crowd in a risky market.
Another thing to understand is that Nokia/Microsoft are in a great position right now, if only they would get aggressive in their marketing. They don't need to go after Android users... they need to convert weary Apple users.
The truth? Windows Phones is now the OLDEST smartphone OS now Symbian has gone the way of the Dodo. MS has been trying for WELL OVER a DECADE.
Completely different UIs. Stylus vs. fingers. Enterprise vs. consumer. Completely different application development and deployment models.
If you can't tell the difference between Windows Mobile and Windows Phone, perhaps you are the blithering idiot. I've driven cars for 15 years, but somebody who has driven big rigs for 5 years will have an advantage at driving big rigs.
The problem is we are graduating a lot of attorneys with $150K+ school debt
Reduce the graduation rate, supply and demand will increase their fees.
But I do agree with your sentiment, so far as I think law is way too complicated. We have laws that fix laws that fix laws that fix laws that fix laws, all the way back to when the first laws fixed laws. "Refactor" is a concept that needs more use in that field.
Go up to an American cop, standing outside a blazing building, and tell them you were there before the fire and brought a torch to light the place up. See how well that goes for you.
Oh, and another strategy is to have a separate server (or servers) dedicated to running the algorithm from password decryption through hash comparison. This server would never be supplied with the user ID, just the encrypted password and the stored hash. If either server had a rootkit (but not both), neither would have enough information to associate the user ID with the plaintext password.
The problem here is that the rootkit could be sophisticated enough to rewrite the output, always returning "true" when it sees a particular input (thus allowing an attacker to login as any user). But at least the password is never compromised, and if that same password is used in multiple systems, the other systems would remain safe.
The password is transmitted encrypted, and stays that way until you apply the decryption algorithm. The encrypted password is decrypted in a for loop, byte by byte, using the same memory address (so that the previous byte is overwritten each iteration).
Now for this to work properly in theory, your comparison or hashing function must also be callable on a per-byte basis. This is usually not the case (and may open another can of worms if you tried), so in practice at some point, the point in which your hashing function is called, the entire password is in memory at once in order to be supplied as a parameter to the hash function. The main point is to reduce the time that it is in memory in unencrypted form, so as soon as that function returns, the password memory location should be overwritten.
No such system is perfect against a rootkit. A rootkit could access all your encrypted passwords and call your decryption function. The point, I suppose, is to make it as difficult as possible. It can help to have N servers evaluating passwords so that the number of passwords ever in jeopardy by a single rootkit are the number checked while the rootkit exists divided by N.
Honestly, it amazes me that the advice for websites is to use something like a hashing algorithm to store passwords, not some kind of public/private key handshake like SRP.
This is bad advice! If the private key is compromised, the password or potentially the entire database of passwords is at risk. If a database of hashes were compromised, there is no key that could ever exist that could extract the original data, because that original data is destroyed in the process of hashing.
That's not to say that hashing is perfect and needs no thought. Of course, you need to use a hash function that reduces the chance of a collision, and you need to make sure your database is not susceptible to rainbow table attacks. For passwords, it is crucial that you use a hashing algorithm designed for passwords with built-in salting and multiple iterations, such as scrypt or bcrypt.
That means that the unencrypted password is in memory on the server, just as the GP stated.
But the OP said that encrypted data is a joke. This is a flat lie. We are talking about millions of encrypted or hashed passwords in a database, versus just a few that are plaintext in memory at any point in time.
And depending on implementation, there are strategies for keeping the password in memory for absolutely as small of a time as possible, even to the point that only a byte or even fewer bits of the password are ever in memory at any given time.
If you don't understand this... well, I'll quote someone we both can agree with:
Slashdot Mirror
Assume for a minute that the OS is doing its job. Then no, you can't install userland rootkits. You can't install background startup programs.
If the attacker has access to your session, you have lost.
No. If my session limits the attacker, then I most certainly have not lost.
If an attacker has access to your machine and you have not used disk encryption, you have lost.
But I have disk encryption. So how have I lost?
if you were willing to place money on the line I could easily write you a service in AutoIt or Powershell which scrapes all of your "secured" firefox passwords and mails them to me with nothing more required than the ability to drop a file somewhere in your user profile.
Who said Firefox was doing things any better?
I will bet money that you can't do the same to my Keepass database.
Said bad guy can dump all your session cookies, grab your history, install malicious extension to intercept all your browsing activity, or install OS user account level monitoring software
This assumes bad guy has access to an account with root/admin access. How about OS accounts that are locked down, for the exact reason of preventing these types of exploits? Obviously Chrome can run on a limited account.
It is irresponsible to rely on the underlying OS security (or insecurity) as a crutch. So what if someone has physical access? Just because they can type on a keyboard or insert a USB drive, doesn't mean they can run an exploit. What will they do, install a rootkit? What if they can't reboot the computer? What if they can't get past BIOS and full disk encryption?
Seriously... I'm getting mad just at the thought that the head of any computer security team can think in this way.
The term "catholic" means "universal" or "general". The earliest churches of Christ were catholic, not Catholic.
What those churches and followers of Christ were, and what Catholicism is today, are as different as night and day. The Catholic religion's belief system is not founded by scripture.
If using the keys is possible then extracting the keys are possible.
Using this line of thought, we should get rid of computer cryptography. After all, it's possible to crack any cryptographic system, just very unlikely.
You may not like storing keys in code... I certainly don't like it either... but sometimes the requirements are non-negotiable. What you do then is make it as secure as possible, and if obfuscation helps, then we use it.
No, I meant SQL injection.
Obfuscation can help reduce the chances of finding an exploitable route for SQL injection. If I am trying to break a complex piece of software, and the field that is susceptible to SQL injection is guarded by dozens of conditions, then it may be easier to decompile the program and attempt to find SQL strings with concatenation and then see where they are are not being sanitized.
And of course I'm not talking about building the software with a trojan/backdoor. I'm talking about a way in which an attacker gets access to your machine. At that point, the attacker still may not have root/administrator access, but may be able to read the software file in question. That's why obfuscation is important, it is another layer of obscurity in case enough real security measures are broken.
Many Christians believe Catholicism is a perversion. It certainly was back in the days of indulgences, but even today it is built on a foundation that doesn't hold up to scripture. In many cases, Catholics rally behind ideas that Jesus even rebuked (but to be fair, that can be said about several other "Christian" doctrines and about many who call themselves Christian).
Seriously, other than making personal computing become something from communist russia, what is the benefit of this?
Security. One major benefit of obfuscation is making it much more difficult to find local data store encryption keys, service endpoints, etc. It makes it harder to find bugs/exploits such as SQL injection.
Remember that not all attacks are aimed at the software in general. Many, many attacks on medical/banking/government systems are aimed at finding specific data on specific computers, and the attacker isn't running it on a VM. These attacks rely on perhaps a trojan or backdoor. The harder it is to build such an attack, the better.
Information is knowledge, knowledge is power, and cheap smartphones help information flow.
Tell me again how that has anything to do with medieval practices? It's not like I'm beating a guy for spreading that knowledge.
Oh wait...
A different judge would have convicted Badawi of apostasy and sentenced him to death. Remember that when you get an urge to say this judge's sentence is barbaric.
[citation needed]
I'm pretty damn sure an American judge absolutely would not.
Westboro is estimated at 40 people out of 2.1 billion Christians worldwide. 0.0000019%
Wahhabism is estimated at 20 million people out of 1.5 billion Muslims worldwide. 1.3%
Yeah, they're the exact same thing.
It's a safe bet that anyone playing "spot the logical fallacy" literally doesn't know the first thing about critical thinking
Critical thinking leads me to the conclusion that Slashdot is not a place where much critical thinking occurs.
Does the religion not dictate the politics and the legal aspects of their society?
https://yourlogicalfallacyis.com/
Remember this when you get an urge to say that America and Western society is oppressive, and when you decide that Islam is a peaceful religion.
Except that Nokia could have dominated Android.
Doubtful. Every company in the Android space is trying to dominate it. But Android is a seriously competitive market within itself.
I would agree if you proposed that Nokia may have had better sales by this point. It's up to them to decide whether to get lost in the crowd in a good market, or stand out from the crowd in a risky market.
Another thing to understand is that Nokia/Microsoft are in a great position right now, if only they would get aggressive in their marketing. They don't need to go after Android users... they need to convert weary Apple users.
The truth? Windows Phones is now the OLDEST smartphone OS now Symbian has gone the way of the Dodo. MS has been trying for WELL OVER a DECADE.
Completely different UIs. Stylus vs. fingers. Enterprise vs. consumer. Completely different application development and deployment models.
If you can't tell the difference between Windows Mobile and Windows Phone, perhaps you are the blithering idiot. I've driven cars for 15 years, but somebody who has driven big rigs for 5 years will have an advantage at driving big rigs.
The problem is we are graduating a lot of attorneys with $150K+ school debt
Reduce the graduation rate, supply and demand will increase their fees.
But I do agree with your sentiment, so far as I think law is way too complicated. We have laws that fix laws that fix laws that fix laws that fix laws, all the way back to when the first laws fixed laws. "Refactor" is a concept that needs more use in that field.
In other words, Lightning exists in our own spacetime.
Go up to an American cop, standing outside a blazing building, and tell them you were there before the fire and brought a torch to light the place up. See how well that goes for you.
Funny, even though the article says that Windows 95 was the peak for Microsoft, the same article says
PC sales were 59m units in 1995 and rose to over 350m in 2012
I'll be glad to take some of that failure off their hands.
Oh, and another strategy is to have a separate server (or servers) dedicated to running the algorithm from password decryption through hash comparison. This server would never be supplied with the user ID, just the encrypted password and the stored hash. If either server had a rootkit (but not both), neither would have enough information to associate the user ID with the plaintext password.
The problem here is that the rootkit could be sophisticated enough to rewrite the output, always returning "true" when it sees a particular input (thus allowing an attacker to login as any user). But at least the password is never compromised, and if that same password is used in multiple systems, the other systems would remain safe.
Moral of the story: don't get rootkits.
The password is transmitted encrypted, and stays that way until you apply the decryption algorithm. The encrypted password is decrypted in a for loop, byte by byte, using the same memory address (so that the previous byte is overwritten each iteration).
Now for this to work properly in theory, your comparison or hashing function must also be callable on a per-byte basis. This is usually not the case (and may open another can of worms if you tried), so in practice at some point, the point in which your hashing function is called, the entire password is in memory at once in order to be supplied as a parameter to the hash function. The main point is to reduce the time that it is in memory in unencrypted form, so as soon as that function returns, the password memory location should be overwritten.
No such system is perfect against a rootkit. A rootkit could access all your encrypted passwords and call your decryption function. The point, I suppose, is to make it as difficult as possible. It can help to have N servers evaluating passwords so that the number of passwords ever in jeopardy by a single rootkit are the number checked while the rootkit exists divided by N.
Honestly, it amazes me that the advice for websites is to use something like a hashing algorithm to store passwords, not some kind of public/private key handshake like SRP.
This is bad advice! If the private key is compromised, the password or potentially the entire database of passwords is at risk. If a database of hashes were compromised, there is no key that could ever exist that could extract the original data, because that original data is destroyed in the process of hashing.
That's not to say that hashing is perfect and needs no thought. Of course, you need to use a hash function that reduces the chance of a collision, and you need to make sure your database is not susceptible to rainbow table attacks. For passwords, it is crucial that you use a hashing algorithm designed for passwords with built-in salting and multiple iterations, such as scrypt or bcrypt.
That means that the unencrypted password is in memory on the server, just as the GP stated.
But the OP said that encrypted data is a joke. This is a flat lie. We are talking about millions of encrypted or hashed passwords in a database, versus just a few that are plaintext in memory at any point in time.
And depending on implementation, there are strategies for keeping the password in memory for absolutely as small of a time as possible, even to the point that only a byte or even fewer bits of the password are ever in memory at any given time.
If you don't understand this... well, I'll quote someone we both can agree with:
You don't deserve to work in IT, either.
Practically every smartphone produced after 2007 ripped off the iPhone. You can't truthfully deny that the iPhone revolutionized smartphones.