About a year ago, I decided to leave the company I was working for, and see if I could find a new challange. I shot my resume to Dice.com, and withen a week, had dozens of calls from headhunters and VP of Engineers. I interviewed at five of these companies; all were dot-coms.
I finally settled on the one that I am in today, and do not regret the decision. My deciding factor was not the whiz-bang technology, nor the hype, but a)My gut-level feeling about my boss (He is the CTO, with over 20 years experience in the field), and b)their business plan. While we continue to have a bit of a burn rate, we started with a solid business plan and a strong management team to develop it.
The result: I work at a stable dot-com, where I am constantly challenged, that is a market leader in our business area, and is working to be profitable withen the next two years.
I've never experienced the horror stories that people have eluded to. Yes, we have been "Tightening our Belt" so to speak, but that is simply to avoid becoming a business casuality.
By the way: Three of the other four companies I interviewed at have sence gone under.
Not really. It requires the storing of a tolken that represents a credit card number on a central, easily accessible server. Transactions can be dumped from this central server every so often, allowing batch processing of orders, where tolkens are matched with the actual credit card numbers offline in the course of the processing.
Of course, this doesn't allow for real-time processing of orders, but it has been my experience that most online transactions are not performed in real-time anyways.
This would prevent en masse abuse of credit card numbers if this central server is compromised (like the CDUniverse incident last year). Without a better understanding of the protocol developed to process orders, I can only guess, though.
I'm writing a paper for review on this subject, based on systems I have developed. I'll post a link to it once it's completed (although I'm sure my hosted site can't handle the Slashdot effect).
No, but there have been several other exploits discussed on Bugtraq this past week with OpenBSD that definately ARE root exploits (xlock, and format string errors in pw_error).
I just posted the above because I thought it was humerous. OpenBSD is not secure just because Theo tells you it is, or there is no open bug in an OpenBSD bug list.
And no, a DoS is not a root hack, but in this case, was easily preventable. The above occured because it slipped through OpenBSD's code review process, proving again that we are all human, that we all make mistakes, and that OpenBSD's open arrogance concerning their security doesn't amount to much of anything.
(People shouldn't throw stones at glass houses)
Besides...remember when it was discovered how volunerable NT was to teardrop attacks? This was also a DoS. It was due to poor coding on the part of the developers, and many of us in the security community held Windows very accountable to their stupidity.
Why should OpenBSD get any better treatment, especially when they claim to be so secure, and their code review so intensive?
Umm....in regards to OpenBSD, you should also show your boss this...
From skyper@SEGFAULT.NET Thu Oct 5 11:28:01 2000
Date: Thu, 5 Oct 2000 18:40:16 +0000
From: skyper
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: obsd_fun.c
"hello hello obsd team. my obsd box panics every few seconds.
what the hell is wrong?"
"oh ? really ? hmm...out of space in kmem_map ?"
"YES. you know about this bug ?"
"yes. some kiddo is running a DoS against your box.
we fixed it in 2.7. the kernel runs out of memory if you
flood it with arp-request...but..psssstt..."
"oh. ok. i wont tell anyone. ive heard of some
other exploits for obsd. maybe its time to change
the 'Three years without a remote hole in the default install!'
to '3 years without releasing an advisory' ?"
Both sendmail and portmap are happily running BY DEFAULT.
I don't believe this is true on 2.6 or later.
Last time I installed 2.6, it was true. I have not played with 2.7 yet, so this may no longer be the case.
troll. backup your assertion: name any significant security issue of obsd 2.6 or later. even in the default install. I've checked its buglist - have you? or are you just blowing smoke (which I suspect).
Significant security issue: Sendmail and portmap are installed, by default, in 2.6 (I am unaware of 2.7). inetd is enabled by default (even though I believe everything is commented out). Better practice would be to default to tcpdaemon instead of inetd, and qmail instead of sendmail. Or to install neither by default.
(Try suggesting this to Theo. Enjoy the flames that follow.)
Are you so much a zealot that you believe that the only bugs that can ever exist in OpenBSD are the one's that appear on a buglist? This is not a troll; it just runs counter to your beliefs. This is what will get your systems compromised; complacency.
OpenBSD does have the right idea when it comes to security (compared to other free *nix), but you have to remember that you cannot ever prove anything secure. All you can honestly say is that, to the best of your knowlege, there are no known security issues. Security cannot be proven, but insecurity can.
It has been my experience that it is best to assume all machines can be compromised. A security syadmin then sets about the task of making things more and more difficult to exploit.
Besides, sucessful application of social engineering will foil the best system security ALWAYS. Thieves don't always pick a lock to get into a home; they break windows as well.
the point is that linux attracts a lot of inexperienced unix users (who have little or no admin background). as such, if linux is to stay viable in the server market, it must protect its image.
I agree with this stance, and am doing something about it. I am in the process of making security documentation that I have written available under an open documentation license (It is currently owned by my employer, so this takes a little convincing). I intend to submit this documentation to friends at Red Hat, in the hopes that it can be put to good use.
As a sysadmin who specializes in security, I have to take issue with your statements. NO machine is ever secure, regardless of OS. Any machine can be compromised.
First on OpenBSD: ever run nmap on a fresh install of OpenBSD? Both sendmail and portmap are happily running BY DEFAULT. Two of the most insecure applications ever written. All OpenBSD really does is give it's users a false sence of security.
Secondly, on Red Hat: It is my opinion that the reason that Red Hat is getting this attention is that it is by far the most used Linux distro. I often build systems based on Red Hat, because I know what I am doing.
You can spend hours and hours of time, securing a box, and if someone can use social engineering to get a username and password, it's all for nothing. This is the biggest issue when it comes to security.
(As an aside: I recently taught a seminar to a company on social engineering. They had never even heard of the concept before. Do you know what they do? Provide customer service for over a dozen banks. Scary.)
I would suggest that this is bordering on overkill. There are lots of brick-and-mortar businesses that handle credit cards without needing precautions like those.
There is no such thing as overkill security; only difficulties in implementation because of the extra work it places in production.
In online business, credit card theft is much rarer, but it is more devastating, because it is usually many thousands of credit cards at once, rather than just one or two carbon reciepts stolen out of the waste basket.
Don't get complacent...
Absolutely. This is just one component in an overall security policy. Trust me; there is MUCH, MUCH more to the systems I have built than this.
What might be even better would be a Java applet running on the client side doing the encryption there. That way the plaintext never even enters the server.
Unfortunately, the legality of this is still in question with current US crypto laws. This would also be very difficult to implement, due to differences in java runtime environments, etc, etc. But it is an interesting idea.
On the production servers. It doesn't matter where the public key is, because you can only encrypt with it. You cannot derive the plaintext from only the public key when you use a well tested (both mathematically and in practice) asymetric algorithm. You can tatoo the public key on your forehead if you like; it is no less secure.
(Of course, with credit card numbers, you have very real problems with known-plaintext attacks. These are dealt with quite easily; I'll leave that answer as an exercise for the reader.)
And what has this bought you, at all?
It's pretty obvious you don't work with financial data.
It has bought you (close to) airtight security. The database containing the encrypted card numbers could be completely compromised, and it doesn't matter. Without access to the private key, they cannot be decrypted in our lifetime (Of course, this assumes our current understanding of mathematics.)
What many people fail to realize is that for most credit card transactions, the vendor has to keep a record of the cards. You cannot simply discard them. Most businesses have to keep them indefinately.
Doing it this way is much more secure than storing them in a locked file cabinet somewhere.
but its only advantage seems to be having the numbers stored on a non-networked machine
Again, it is very apparant you don't work with financial data. The card numbers have to be downloaded in batches. Because the decryption machine is physically seperate from all other networks, you cannot do this in real time. The encrypted cards have to be stored SOMEWHERE before you download them; without the proper use of an asymetric algorithm, they would be stored in plain text in a database (a bad idea, remember?), or encrypted with a SYMETRIC algorithm, which is just as good as storing them plaintext (In a symetric algorithm, the same key used to encrypt also decrypts. Because you would have to store the key on the server that encrypts them, the key is subject to compromise)
The correct way to deal with credit cards is to use an asymetiric algorithm (public-key) encryption, where the private key exists only on a system that has no connection to any network. The encrypted data is then pushed to a floppy/zip/etc, where is is processed by human hands at the secured processing machine. The processing machine is then protected by physical means (cages, keys, cameras), and is done by a person who has been deemed trustable (background checks, etc).
An important component is that no sysadmin at the company has any access to this processsing machine. Only technically inclined executives (i.e. CTO, CIO, COO) have root access to this machine, and if maintence must occur at this machine, the sysadmin is logged into it by the executive, who then physically watches what the sysadmin is doing (and the executive knows his/her shit, so there is no question of foul play).
In this scenaro, if the website is completely compromised and all credit card numbers are stolen, they are completely useless to the cracker, as they cannot be decrypted without that private key.
This is ideal practice, and should be implemented at all e-commerce sites.
I am of the opinion that the release of Star Office will kill, or at least, severely hurt, the other free office software implementations. I am also of the opinion that this is necessarily not a bad thing. It has been my experience (mind you, this is opinion, and I'm sure many will disagree with me) that Star Office is far more robust than the other Linux office packages. It is the one piece of software that prevents me from having to install Windows on a box at work, as I have to read the memos from Bisdev and Marketing as well;-).
Linux, and Unix in general, has thrived on there's more than one way to do it. But this app is targeted at simple end users, not the power users that Linux has traditionally attracted. To an office worker, consistency is the key.
I think it would be better, in the long run, if AbiWord, etc. contributed their code to Star Office, so that we have a solid, fully featured alternative to the Microsoft products.
pardon for not knowing the link offhand, but there was a case where the FBI was able to recover data that had been rewriten over approximately 100 times using such a tool. I remember reading a paper on this (I think it was at Counterpane Labs, but I could be wrong). I'll hunt for the URL and repost.
There is no way Napster can promote Indy bands. You search for a band because you already know about it, meaning a)the marketing matrix has you, Neo b)word of mouth c)saw a story about the band somewhere d)band is local to your area (modified a && b). If you don't know about the band, you can't search for it.
This is not the case at all. Recently, there was discovery of a bug in PGP that made it possible to guess keys. See http://www.securityfocus.com/bid/1251
There have been several other bugs found in PGP; I can't remember the specifics, but I believe that the above bug was in PGP for over a year for being discovered, in spite of the fact that the code was open for everyone to see.
If you've ever actually looked at the code for PGP, you'll see it's HORRIBLE. PGP is coded really sloppily. My comments were more directed at the high probability of an acidental implementation error due to programming practice, not an intentional crippling.
This is particularly the case with Open Source projects, as willingness to code something rarely translates to being the best person to do it. Bruce Schneier commented on this in his Cryptogram newsletter. See:
http://www.counterpane.com/crypto-gram-9909.html
http://www.counterpane.com/pitfalls.html
http://www.counterpane.com/whycrypto.html
And please, this isn't a flame. This is born out of experience.
While you are correct in your statement that PGP has never been "cracked", this is an over-simplistic view of the software's strength. Any mismanagement of the way the protocols are used could possibly weaken the crypto, which could be enough to be cracked. The algorythms are only as secure as they proport to be when they are implemented according to their reference implementation. While no one has the computing power to brut-force full strength RSA, perhaps an inadvertantly crippled RSA could be broken. This is a big problem with any crypto implementation.
The OpenBSD security is a marketing myth. The security of a system has everything to do with the compentency and vigilance of the admin, and very little to do with the operating system (The exception here are Windows 9* boxen, which cannot be secured by design).
Have you actually used OpenBSD? The install has sendmail and portmap running by default. You have to manually remove this services.
All the bragging about OpenBSD being SO secure does is give the admin a false sence of security. EVERY machine can be compromised. EVERY ONE. The job of a good admin is to constantly raise the bar; to make it more and more difficult for a cracker to get in.
Besides: if a cracker can social engineer someone into giving him their password, then the system security doesn't mean shit. Humans are ALWAYS the weakest link in any security policy.
The company I work for offers cookie-based registration, but does not require it for use. It is actually benifitical to the user to accept cookies on our site. We don't sell demographics, and we respect our users privacy.
You get sane design like this when your "Team of Geeks" who built the site are sensitve to privacy issues. The best of both worlds.
Unfortunately, I can't give you the url, as I am sensitive to MY privacy:-)
The answer here is simple. By offering goods and services that bring convience or benifit to consumers. Online businesses should be treated no different than meatspace businesses, except with a web-based interface that provides 24-hour access without the overhead of a brick and mortar.
A solid business model is the key. If the company is trying to make the business work, rather than cashing in on the "dot-com" frenzy, they will survive. Nobody but Yahoo or C-Net can make money on advertising.
As an aside to this: In my last round of looking for work, I received three offers; all three from start-ups in Menlo Park. I chose the company that, to me, had the best future. The result: The company I work for now is the only one of the three still in business. We will be going public later this year, in spite of the stock market dry up, as we have solid business practices and offer services that bring value to customers.
Wrong again. The good sysadmins ignore CERT, and spend their time groking the cracker sites. Their servers don't touch a net wire until the box is secure. The good sysadmins realize that over 90% of system crack attempts come from internal employees who have at least some level of legitimate access to the system. The good sysadmins work closely with the C?O's of the company, making falling for most common social engineering pranks grounds for immediate termination.
Good sysadmins have their own private networks where they abuse their own systems. They don't believe a word of market-speak about any product unless they can verify it in testing and with common sence (market speak such as OpenBSD being secure "out of the box". Secure - and running NFS and sendmail OUT OF THE BOX BY DEFAULT. Very dumb.).
Good sysadmins are differentiated from the really good crackers only by ethical choice. They are just as dedicated to the security and integrity of their systems as the hardcore cracker is dedicated to exploiting them.
>>The real victim in a crack-back would be his isp and all the intermittant hops in between you and him.
This was directed mostly at a retalitory DoS attack. The flood of traffic has to be passed router to router to his box; this can certainly affect his isp. Imagine what happens if he's located on a cable modem? Everyone on his neighborhood segment is affected.
>>I've done some security assessment/expert witness testimony regarding cracks on business systems. I was involved in one case where it was thrown out of court because the sysadmin retaliated.
>Well, he was only attacking my home system, so I really can't see where I would have taken the time or expense to prosecute anyway. (not that that justifies anything)
Let's say that he spoofs an ip address that belongs to a large company. Or, that he works for that company, and is using their equipment to crack your machine. If the company is smart, they will most definately bring charges against you for your retaliation strike. Although I've not been involved in any cases like this, I have seen it happen.
Sounds like you're just as clueless to how the Internet really works.
1. Even if the cracker is really coming from the ip address in your logs, he doesn't "own" it at all. The real victim in a crack-back would be his isp and all the intermittant hops in between you and him.
2. In the United States, there is no "self-defense" clause in any of the laws governing cracking. This means, regardless of the circumstances, it is a federal offence to retaliate. I don't know of the laws in other countries.
3. I've done some security assessment/expert witness testimony regarding cracks on business systems. I was involved in one case where it was thrown out of court because the sysadmin retaliated.
4. 99.9999999% of the crackers out there are script kiddies. All you have to do to keep them out is stay on top of the security policy of your site. A multi-layered approach to network security will keep your network protected.
5. Because of #4, if you are cracked, even though it doesn't excuse it, it usually IS your own damn fault. (I would never tell this to a client, though). Spend the time during the crack gathering as much data as you can regarding your cracker, and spend the time afterwords upgrading the site security.
I am designing a data-mining system at work, and I believe that this far surpasses Linux's ability to scale. The problem is, Linux only supports files up to 2GB in size(4GB with reserf), and MySQL only supports 4GB tables. I estimate that several tables will exceed 20GB in size, and breaking them up into smaller tables will be highly inefficient. We've just pushed Linux as far as it can currently go.
So A big Sun box and Oracle are going to be the back end. Even Oracle on Linux runs into the filesize limit, because of the lack of raw device access in the kernel.
Sometimes, free software isn't the way to go. You have to pick the right tool for the job.
Lest any of us forget, while NT servers can be made reasonably stable and secure with work, MS software in its default configuration is generally not set up to be secure
Not to start a flame war or anything, but all distributions of Linux (all that I have worked with, YMMV) are just as insecure "Out of the Box" as NT is. Even OpenBSD, touted as the most secure OS, has sendmail and NFS running by default after the initial install (again, YMMV - This was my experience during my last install of the base OpenBSD 2.6 packages from CD.).
As Bruce Schneier has said, "security is a process". My servers must be constantly updated to protect against security compromises. Most security compromises don't come from that "'leet d00d" that the media is so quick to play up - most occur from internal employees. Protecting systems from them is a WORLD of difference than protecting them from J. Random Script Kiddie.
Slashdot Mirror
About a year ago, I decided to leave the company I was working for, and see if I could find a new challange. I shot my resume to Dice.com, and withen a week, had dozens of calls from headhunters and VP of Engineers. I interviewed at five of these companies; all were dot-coms.
I finally settled on the one that I am in today, and do not regret the decision. My deciding factor was not the whiz-bang technology, nor the hype, but a)My gut-level feeling about my boss (He is the CTO, with over 20 years experience in the field), and b)their business plan. While we continue to have a bit of a burn rate, we started with a solid business plan and a strong management team to develop it.
The result: I work at a stable dot-com, where I am constantly challenged, that is a market leader in our business area, and is working to be profitable withen the next two years.
I've never experienced the horror stories that people have eluded to. Yes, we have been "Tightening our Belt" so to speak, but that is simply to avoid becoming a business casuality.
By the way: Three of the other four companies I interviewed at have sence gone under.
Not really. It requires the storing of a tolken that represents a credit card number on a central, easily accessible server. Transactions can be dumped from this central server every so often, allowing batch processing of orders, where tolkens are matched with the actual credit card numbers offline in the course of the processing.
Of course, this doesn't allow for real-time processing of orders, but it has been my experience that most online transactions are not performed in real-time anyways.
This would prevent en masse abuse of credit card numbers if this central server is compromised (like the CDUniverse incident last year). Without a better understanding of the protocol developed to process orders, I can only guess, though.
I'm writing a paper for review on this subject, based on systems I have developed. I'll post a link to it once it's completed (although I'm sure my hosted site can't handle the Slashdot effect).
This part is easy:
/root]# rm -rf /home
[root@bofh
:-)
No, but there have been several other exploits discussed on Bugtraq this past week with OpenBSD that definately ARE root exploits (xlock, and format string errors in pw_error).
I just posted the above because I thought it was humerous. OpenBSD is not secure just because Theo tells you it is, or there is no open bug in an OpenBSD bug list.
And no, a DoS is not a root hack, but in this case, was easily preventable. The above occured because it slipped through OpenBSD's code review process, proving again that we are all human, that we all make mistakes, and that OpenBSD's open arrogance concerning their security doesn't amount to much of anything.
(People shouldn't throw stones at glass houses)
Besides...remember when it was discovered how volunerable NT was to teardrop attacks? This was also a DoS. It was due to poor coding on the part of the developers, and many of us in the security community held Windows very accountable to their stupidity.
Why should OpenBSD get any better treatment, especially when they claim to be so secure, and their code review so intensive?
Umm....in regards to OpenBSD, you should also show your boss this...
..but..psssstt..."
From skyper@SEGFAULT.NET Thu Oct 5 11:28:01 2000
Date: Thu, 5 Oct 2000 18:40:16 +0000
From: skyper
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: obsd_fun.c
"hello hello obsd team. my obsd box panics every few seconds.
what the hell is wrong?"
"oh ? really ? hmm...out of space in kmem_map ?"
"YES. you know about this bug ?"
"yes. some kiddo is running a DoS against your box.
we fixed it in 2.7. the kernel runs out of memory if you
flood it with arp-request.
"oh. ok. i wont tell anyone. ive heard of some
other exploits for obsd. maybe its time to change
the 'Three years without a remote hole in the default install!'
to '3 years without releasing an advisory' ?"
(Exploit snipped due to ethics)
More like 19 if you count only HIGH or SECURITY. (Posted from a test RH 7.0 Box)
Both sendmail and portmap are happily running BY DEFAULT.
I don't believe this is true on 2.6 or later.
Last time I installed 2.6, it was true. I have not played with 2.7 yet, so this may no longer be the case.
troll. backup your assertion: name any significant security issue of obsd 2.6 or later. even in the default install. I've checked its buglist - have you? or are you just blowing smoke (which I suspect).
Significant security issue: Sendmail and portmap are installed, by default, in 2.6 (I am unaware of 2.7). inetd is enabled by default (even though I believe everything is commented out). Better practice would be to default to tcpdaemon instead of inetd, and qmail instead of sendmail. Or to install neither by default.
(Try suggesting this to Theo. Enjoy the flames that follow.)
Are you so much a zealot that you believe that the only bugs that can ever exist in OpenBSD are the one's that appear on a buglist? This is not a troll; it just runs counter to your beliefs. This is what will get your systems compromised; complacency.
OpenBSD does have the right idea when it comes to security (compared to other free *nix), but you have to remember that you cannot ever prove anything secure. All you can honestly say is that, to the best of your knowlege, there are no known security issues. Security cannot be proven, but insecurity can.
It has been my experience that it is best to assume all machines can be compromised. A security syadmin then sets about the task of making things more and more difficult to exploit.
Besides, sucessful application of social engineering will foil the best system security ALWAYS. Thieves don't always pick a lock to get into a home; they break windows as well.
the point is that linux attracts a lot of inexperienced unix users (who have little or no admin background). as such, if linux is to stay viable in the server market, it must protect its image.
I agree with this stance, and am doing something about it. I am in the process of making security documentation that I have written available under an open documentation license (It is currently owned by my employer, so this takes a little convincing). I intend to submit this documentation to friends at Red Hat, in the hopes that it can be put to good use.
What are you doing?
As a sysadmin who specializes in security, I have to take issue with your statements. NO machine is ever secure, regardless of OS. Any machine can be compromised.
First on OpenBSD: ever run nmap on a fresh install of OpenBSD? Both sendmail and portmap are happily running BY DEFAULT. Two of the most insecure applications ever written. All OpenBSD really does is give it's users a false sence of security.
Secondly, on Red Hat: It is my opinion that the reason that Red Hat is getting this attention is that it is by far the most used Linux distro. I often build systems based on Red Hat, because I know what I am doing.
You can spend hours and hours of time, securing a box, and if someone can use social engineering to get a username and password, it's all for nothing. This is the biggest issue when it comes to security.
(As an aside: I recently taught a seminar to a company on social engineering. They had never even heard of the concept before. Do you know what they do? Provide customer service for over a dozen banks. Scary.)
I would suggest that this is bordering on overkill. There are lots of brick-and-mortar businesses that handle credit cards without needing precautions like those.
There is no such thing as overkill security; only difficulties in implementation because of the extra work it places in production.
In online business, credit card theft is much rarer, but it is more devastating, because it is usually many thousands of credit cards at once, rather than just one or two carbon reciepts stolen out of the waste basket.
Don't get complacent...
Absolutely. This is just one component in an overall security policy. Trust me; there is MUCH, MUCH more to the systems I have built than this.
What might be even better would be a Java applet running on the client side doing the encryption there. That way the plaintext never even enters the server.
Unfortunately, the legality of this is still in question with current US crypto laws. This would also be very difficult to implement, due to differences in java runtime environments, etc, etc. But it is an interesting idea.
So where's the public key?
On the production servers. It doesn't matter where the public key is, because you can only encrypt with it. You cannot derive the plaintext from only the public key when you use a well tested (both mathematically and in practice) asymetric algorithm. You can tatoo the public key on your forehead if you like; it is no less secure.
(Of course, with credit card numbers, you have very real problems with known-plaintext attacks. These are dealt with quite easily; I'll leave that answer as an exercise for the reader.)
And what has this bought you, at all?
It's pretty obvious you don't work with financial data.
It has bought you (close to) airtight security. The database containing the encrypted card numbers could be completely compromised, and it doesn't matter. Without access to the private key, they cannot be decrypted in our lifetime (Of course, this assumes our current understanding of mathematics.)
What many people fail to realize is that for most credit card transactions, the vendor has to keep a record of the cards. You cannot simply discard them. Most businesses have to keep them indefinately.
Doing it this way is much more secure than storing them in a locked file cabinet somewhere.
but its only advantage seems to be having the numbers stored on a non-networked machine
Again, it is very apparant you don't work with financial data. The card numbers have to be downloaded in batches. Because the decryption machine is physically seperate from all other networks, you cannot do this in real time. The encrypted cards have to be stored SOMEWHERE before you download them; without the proper use of an asymetric algorithm, they would be stored in plain text in a database (a bad idea, remember?), or encrypted with a SYMETRIC algorithm, which is just as good as storing them plaintext (In a symetric algorithm, the same key used to encrypt also decrypts. Because you would have to store the key on the server that encrypts them, the key is subject to compromise)
The correct way to deal with credit cards is to use an asymetiric algorithm (public-key) encryption, where the private key exists only on a system that has no connection to any network. The encrypted data is then pushed to a floppy/zip/etc, where is is processed by human hands at the secured processing machine. The processing machine is then protected by physical means (cages, keys, cameras), and is done by a person who has been deemed trustable (background checks, etc).
An important component is that no sysadmin at the company has any access to this processsing machine. Only technically inclined executives (i.e. CTO, CIO, COO) have root access to this machine, and if maintence must occur at this machine, the sysadmin is logged into it by the executive, who then physically watches what the sysadmin is doing (and the executive knows his/her shit, so there is no question of foul play).
In this scenaro, if the website is completely compromised and all credit card numbers are stolen, they are completely useless to the cracker, as they cannot be decrypted without that private key.
This is ideal practice, and should be implemented at all e-commerce sites.
I am of the opinion that the release of Star Office will kill, or at least, severely hurt, the other free office software implementations. I am also of the opinion that this is necessarily not a bad thing. It has been my experience (mind you, this is opinion, and I'm sure many will disagree with me) that Star Office is far more robust than the other Linux office packages. It is the one piece of software that prevents me from having to install Windows on a box at work, as I have to read the memos from Bisdev and Marketing as well ;-).
Linux, and Unix in general, has thrived on there's more than one way to do it. But this app is targeted at simple end users, not the power users that Linux has traditionally attracted. To an office worker, consistency is the key.
I think it would be better, in the long run, if AbiWord, etc. contributed their code to Star Office, so that we have a solid, fully featured alternative to the Microsoft products.
pardon for not knowing the link offhand, but there was a case where the FBI was able to recover data that had been rewriten over approximately 100 times using such a tool. I remember reading a paper on this (I think it was at Counterpane Labs, but I could be wrong). I'll hunt for the URL and repost.
There is no way Napster can promote Indy bands. You search for a band because you already know about it, meaning a)the marketing matrix has you, Neo b)word of mouth c)saw a story about the band somewhere d)band is local to your area (modified a && b). If you don't know about the band, you can't search for it.
This is not the case at all. Recently, there was discovery of a bug in PGP that made it possible to guess keys. See http://www.securityfocus.com/bid/1251
l
There have been several other bugs found in PGP; I can't remember the specifics, but I believe that the above bug was in PGP for over a year for being discovered, in spite of the fact that the code was open for everyone to see.
If you've ever actually looked at the code for PGP, you'll see it's HORRIBLE. PGP is coded really sloppily. My comments were more directed at the high probability of an acidental implementation error due to programming practice, not an intentional crippling.
This is particularly the case with Open Source projects, as willingness to code something rarely translates to being the best person to do it. Bruce Schneier commented on this in his Cryptogram newsletter. See:
http://www.counterpane.com/crypto-gram-9909.htm
http://www.counterpane.com/pitfalls.html
http://www.counterpane.com/whycrypto.html
And please, this isn't a flame. This is born out of experience.
While you are correct in your statement that PGP has never been "cracked", this is an over-simplistic view of the software's strength. Any mismanagement of the way the protocols are used could possibly weaken the crypto, which could be enough to be cracked. The algorythms are only as secure as they proport to be when they are implemented according to their reference implementation. While no one has the computing power to brut-force full strength RSA, perhaps an inadvertantly crippled RSA could be broken. This is a big problem with any crypto implementation.
The OpenBSD security is a marketing myth. The security of a system has everything to do with the compentency and vigilance of the admin, and very little to do with the operating system (The exception here are Windows 9* boxen, which cannot be secured by design).
Have you actually used OpenBSD? The install has sendmail and portmap running by default. You have to manually remove this services.
All the bragging about OpenBSD being SO secure does is give the admin a false sence of security. EVERY machine can be compromised. EVERY ONE. The job of a good admin is to constantly raise the bar; to make it more and more difficult for a cracker to get in.
Besides: if a cracker can social engineer someone into giving him their password, then the system security doesn't mean shit. Humans are ALWAYS the weakest link in any security policy.
The company I work for offers cookie-based registration, but does not require it for use. It is actually benifitical to the user to accept cookies on our site. We don't sell demographics, and we respect our users privacy.
:-)
You get sane design like this when your "Team of Geeks" who built the site are sensitve to privacy issues. The best of both worlds.
Unfortunately, I can't give you the url, as I am sensitive to MY privacy
The answer here is simple. By offering goods and services that bring convience or benifit to consumers. Online businesses should be treated no different than meatspace businesses, except with a web-based interface that provides 24-hour access without the overhead of a brick and mortar.
A solid business model is the key. If the company is trying to make the business work, rather than cashing in on the "dot-com" frenzy, they will survive. Nobody but Yahoo or C-Net can make money on advertising.
As an aside to this: In my last round of looking for work, I received three offers; all three from start-ups in Menlo Park. I chose the company that, to me, had the best future. The result: The company I work for now is the only one of the three still in business. We will be going public later this year, in spite of the stock market dry up, as we have solid business practices and offer services that bring value to customers.
Wrong again. The good sysadmins ignore CERT, and spend their time groking the cracker sites. Their servers don't touch a net wire until the box is secure. The good sysadmins realize that over 90% of system crack attempts come from internal employees who have at least some level of legitimate access to the system. The good sysadmins work closely with the C?O's of the company, making falling for most common social engineering pranks grounds for immediate termination.
Good sysadmins have their own private networks where they abuse their own systems. They don't believe a word of market-speak about any product unless they can verify it in testing and with common sence (market speak such as OpenBSD being secure "out of the box". Secure - and running NFS and sendmail OUT OF THE BOX BY DEFAULT. Very dumb.).
Good sysadmins are differentiated from the really good crackers only by ethical choice. They are just as dedicated to the security and integrity of their systems as the hardcore cracker is dedicated to exploiting them.
>>The real victim in a crack-back would be his isp and all the intermittant hops in between you and him.
This was directed mostly at a retalitory DoS attack. The flood of traffic has to be passed router to router to his box; this can certainly affect his isp. Imagine what happens if he's located on a cable modem? Everyone on his neighborhood segment is affected.
>>I've done some security assessment/expert witness testimony regarding cracks on business systems. I was involved in one case where it was thrown out of court because the sysadmin retaliated.
>Well, he was only attacking my home system, so I really can't see where I would have taken the time or expense to prosecute anyway. (not that that justifies anything)
Let's say that he spoofs an ip address that belongs to a large company. Or, that he works for that company, and is using their equipment to crack your machine. If the company is smart, they will most definately bring charges against you for your retaliation strike. Although I've not been involved in any cases like this, I have seen it happen.
Sounds like you're just as clueless to how the Internet really works.
1. Even if the cracker is really coming from the ip address in your logs, he doesn't "own" it at all. The real victim in a crack-back would be his isp and all the intermittant hops in between you and him.
2. In the United States, there is no "self-defense" clause in any of the laws governing cracking. This means, regardless of the circumstances, it is a federal offence to retaliate. I don't know of the laws in other countries.
3. I've done some security assessment/expert witness testimony regarding cracks on business systems. I was involved in one case where it was thrown out of court because the sysadmin retaliated.
4. 99.9999999% of the crackers out there are script kiddies. All you have to do to keep them out is stay on top of the security policy of your site. A multi-layered approach to network security will keep your network protected.
5. Because of #4, if you are cracked, even though it doesn't excuse it, it usually IS your own damn fault. (I would never tell this to a client, though). Spend the time during the crack gathering as much data as you can regarding your cracker, and spend the time afterwords upgrading the site security.
For those of you who actually USE Linux, Shockwave is available.
And the cartoon is HILARIOUS!!!
I am designing a data-mining system at work, and I believe that this far surpasses Linux's ability to scale. The problem is, Linux only supports files up to 2GB in size(4GB with reserf), and MySQL only supports 4GB tables. I estimate that several tables will exceed 20GB in size, and breaking them up into smaller tables will be highly inefficient. We've just pushed Linux as far as it can currently go.
So A big Sun box and Oracle are going to be the back end. Even Oracle on Linux runs into the filesize limit, because of the lack of raw device access in the kernel.
Sometimes, free software isn't the way to go. You have to pick the right tool for the job.
Lest any of us forget, while NT servers can be made reasonably stable and secure with work, MS software in its default configuration is generally not set up to be secure
Not to start a flame war or anything, but all distributions of Linux (all that I have worked with, YMMV) are just as insecure "Out of the Box" as NT is. Even OpenBSD, touted as the most secure OS, has sendmail and NFS running by default after the initial install (again, YMMV - This was my experience during my last install of the base OpenBSD 2.6 packages from CD.).
As Bruce Schneier has said, "security is a process". My servers must be constantly updated to protect against security compromises. Most security compromises don't come from that "'leet d00d" that the media is so quick to play up - most occur from internal employees. Protecting systems from them is a WORLD of difference than protecting them from J. Random Script Kiddie.