Qualifier: I work as a security/encryption sysadmin. I have a very strong background in math and system security. I've developed several encryption protocols that are in process of peer review. I've been a sysadmin for 7 years, and have programmed fr 15.
First off: [trog@pain trog]$ ros www.paytrust.com Netcraft: [11]www.paytrust.com is running Microsoft-IIS/4.0 on [12]NT4 or Windows 98 www.paytrust.com: Server: Microsoft-IIS/4.0
Not to Microsoft bash, but IIS is extremely insecure. Due to fundemental problems with IIS, it really cannot be secured.
Secondly, with a bill payment that does direct money transfers, you are dealing with actual money, not credit cards. You have less legal protection against fraud here than if you use a credit card. IANAL, but I've worked with them in systems design.
Thirdly, there are really no industry-wide standard security practices. Visa can audit these bill payment companies, but they can only make suggestions, and their recommendations can be(and I have seen businesses who do) completely ignored, with no vendor ramifications.
Forth: A secure system is INCREDIBLY difficult to implement. It requires a vast amount of knowledge and experience that most sysadmin's simply don't have. Not that it can't be learned; it just takes a great deal of time and desire to learn. Add to that the proliferation of paper-MCSE's calling themselves security experts, and all the Internet startups who get their website up and lock the system down later, and you have a definate recepe for disaster.
Fifth: As a consumer, you have absolutely NO WAY of knowing if a site is truly secure. The CdUniverse fiasco happened because they stored their credit card numbers in their database PLAINTEXT. How pathetic.
In fact, most customers compromise their security when they connect to a secure site; the default 40-bit encryption from exportable browsers is trivial to crack.
I would stick to the old "check in the mail" until sysadmins start taking security seriously.
While your experience is great, the reason we are looking for perl programmers is:
1. Our existing code is all in perl, 2. It works, works fast, and works well 3. So why fix what ain't broken?
We are doing some work with PHP, but that's experimental, and may never enter production. If it does, it will work alongside our existing perl code; in the real world, you use the tool that works best for your application.
And I AM NOT a personell dept. - I am the sysadmin for the company. We ask for specific skills because those are the skills we require - the same as any other job in the world. And it is not some HR person that interviews you here; the geeks that you will be working with do that.
The biggest requirement for work here is that you must have that hacker/tinkerers spirit, and must jell well with the other people you are working with. Unfortunately, there is no real way to express that in a resume. While I don't doubt you have the technical background to do the work, the arrogance you just spewed out would kill you in the real world. Where I work, we are all a bunch of really skilled geeks, but we are also good friends.
The job offer is serious; we are looking for perl programmers and a webmaster in an all Linux/OpenBSD environment. If you are interested, let's see a link to the resume.
(I will not post on this subject further, as it seems to be a poor forum to do this)
This is absolutely true. I've been interviewing perl programmers and webmasters for the past month; NONE of them were qualified for the work. Competency can't really be taught; it's aquired through experimentation and experience.
Incidently, if you are a good perl programmer with Linux experience and wish to work at a great stert-up in Menlo Park, CA, reply to this thread with a link to your resume. I will contact you.
Even if we assume parents will usually make good decisions in these matters, where it really gets ugly is when the state decides what constitutes the master race.
and
I think the best uses of this would be to eliminate genetic traits that we can all agree are undesirable
and tell me what is the real difference between the two?
Fact of the matter is: all species engage in genetic selection, humans included. Every being wants the strongest possible offspring. Genetic knowledge just makes this a bit more precise.
ftp passwords are always sent plaintext, so yes, the NORMAL operation of an ftp server on any server on the Internet is on shakey ground. This is particularly true with a home DSL connection, as the box hosting the ftp server tends to be used for many different things (and thus, is more important to the user, and is more distructive when it is compromised.).
If you still want to use an ftp server, I suggest creating specific accounts for ftp usage only, who's shells are/bin/false (can't log in with those accounts, except via ftp - no shell access). Set up your ftp server in a chroot jail. Configure the ftp server to log every connection. While none of these things will prevent your box from being compromised, they all make things much more difficult for the 90% of crackers out there; those running canned scripts, with very little brains.
Remember: The ip addresses of DSL and cable modems are well known to crackers. I monitor my home office (connected via DSL) with all sorts of various and sundry software;-). My systems are port scanned an average of once every ten to twenty minutes, with stealth scan attempts almost as often. Every time I read about a new unix exploit on Bugtraq, I see crackers attempting it sever dozen times in my logs. If you have DSL, this is happening to you as well.
Haven't you read the analysis of the DDoS attacks? The TFN and TFN2000 clients and servers can be configured to run on a port greater than 1024. That means, ANY ACCOUNT ON YOUR SYSTEM CAN RUN THE DDOS ATTACK.
Once one account is compromised, and shell access to the target system can be maintained, compromise of the root account is, in most cases, trivial.
ssh is a secure replacement for telnet. scp is a secure replacement for ftp. There are ssh clients for all common operating systems (though I've never found a scp tool for a non-unix system). You can still offer shell access to your box; just use a service that is more secure.
Your further ignorance, and hostility towards the correct solution further illustrates my point. Arrogance is no substitute for ability. The reason your box wasn't compromised (and it may very well have been, you could just be unaware of it) was pure luck. Nothing more.
telnet and ftp send all data back and forth in plaintext, INCLUDING YOUR PASSWORD. Any network sniffer between you and your box now has captured that account's password. Account compromised. Game over.
Your ignorance on this issue illustrated my point.
Problem is....YOU CAN'T educate the average Joe for security. It is far too involved and can't be solved with some magic pill or simple patch. Networked systems are horribly complex, with interactions on many different levels. It is better to leave the security in the hands of the few who have a passion for it.
Here's my solution: Have all ISP's providing DSL and cable service host the firewall for all their customers. Have them hire vigilant security minded sysadmins (there are few of them, but they are out there), who's only job is to keep the firewalled area secure. This way, Joe DSL doesn't have to worry about it all.
While this solves the problem for the ISP, it leaves Joe DSL without a way to run his own apache server, ftp server, telnet server, for hiw own low-volume stuff, even if he knows how to secure his machine.
If Joe DSL is running telnet or ftp, he MOST CERTAINLY doesn't know how to secure his machine.
As a sysadmin that works exclusively with security issues, I can tell you that the "personal firewall" is a worse solution than having no firewall at all. Security is a process; it is never ending, and requires a great deal of time and effort. Joe DSL is going to install that firewall, and think it will protect him forever. It creates a false sence of security.
Security cannot be left to people who don't constantly work to improve it. Joe DSL has neither the ability nor the desire to do this. Sadly, neither do most self-styled sysadmins.
You can't have it both ways. Either you aim for widespread acceptance of Linux (in which case, AOL must be embraced), or Linux remains the odd box in the server closet.
It is not only the illiterate users who use AOL. My fience, who is obtaining her teaching credentials, uses AOL on her iMac. She's very bright and intelligent, but when it comes to computers, she just wants to use them as a tool - nothing more. She has no desire to learn Linux. She just wants something that works, and will work without a minimum of fuss. This is what 90% of the people out there want.
When we are married later this year, that purple iMac is going to fit right into my home office, next to my Sparc, OpenBSD and Linux boxen. She'll keep her AOL, because that's what works for her.
If you really want the masses to use Linux, you can stand to learn a thing or two from that iMac.
The fact is that ANY server running on ANY OS without the proper cryptographic processing of the data before it is stored is the most important component of data security. If the data is stored in an SQL database unencrypted, if the server is compromised, the data belongs to the cracker.
An "e-commerce" server should have a two tier model for security. The first tier is Server security, which is what most of the uninformed are flaming about. The second tier, and MOST IMPORTANT, is data security. The data needs to be cryptographically processed in such a way that if the server is completely compromised, the data is completely useless to the cracker.
This takes a GREAT deal of skill and craft to successfully implement. Herein lies the problem: companies are so motivated to get the e-commerce thing going NOW that they leave themselves wide open.
The point of my post is that once they are encrypted properly, you can damn near store the encrypted card numbers in your.sig file - ain't no one gonna decrypt them.
There are several reasons for storing the credit card number on the server. Monthly billing, future purchases, etc. etc.
As for the processor, I can't disclose (under NDA)
This response was obviously from someone who doesn't deal with either cryptography or "e-commerce" (I HATE that buzzword).
Secure cc transactions require a multi-layered cryptographic approach. The protocol used in the receiving of the cc numbers is much different then what is done when you store the numbers. If you a)process a credit card number with a cryptographically secure PRNG (cc's are VERY PREDICTIBLE), sign treated cc numbers before encrypting, and use an asymetric encryption algorithm with large keys that has shown to be strong (and the server only has the public key stored on it), YOU CAN SAFELY STORE THE CREDIT CARD NUMBER ON THE SERVER. Only the credit card processor has the private key, and the cc numbers should NEVER be decrypted on a system connected to the Internet.
If a server is set up this way, and the entire credit card database is downloaded to some script kiddie's system, they are still useless. I've never met a script kiddie that could decrypt randomized credit card numbers with 2048-bit RSA keys.
The problem is that the proper use and implementation of cryptography is amazingly difficult. I've been dealing with encryption for five years, and e-commerce sites for about two years; even most "Unix Guru's" don't get it right. It takes a lot of time and specialized knowledge.
You are refering to a symmetric algorithm (I am inferring this from your reference to ssl, which requires a symetric algorithm). In this case, yes, you are correct; however, (if implemented correctly), ssl will encrypt a unique session key, that changes with each new connection. With a unique session key, you still cannot decrypt the data, as it is encrypted with both the session key and the symetric cipher.
The article appears (at least to me) to be refering to public key encryption, such as used in PGP. These protocols make use of asymetric algorithms, which require two unique keys - a public and private. You can encrypt messages with either key, but you cannot derive on key from the other.
The key to security here is having only the public key available on a system connected to the Internet. While you still must guard against sideband attacks, this makes a brut force attack against the crypto infeasable.
Yes, I am suggesting that the data is re-encrypted and passed to a secured vault server. And yes, it is a very, very good idea.
It appears that the article is discussing a flaw in the implimentation of an asymetrical algorithm, such as ElGamel or RSA. Real easy solution folks - the server that is actually taking credit card numbers should only have the public key stored on it. There is no need for the private key to be on any public accessable system, as the decryption of the card data is done only by the card processor, which is never done on a system connected to the Internet.
You also must introduce randomness to the credit card data before encrypting, because the regularity of credit card numbers allows a cracker to make a known-plaintext attack.
I've been dealing with security and encryption with e-commerse for about two years. Anyone who would set up a system like that discussed in the article is a rank amateur and a fool.
My room-mate just bought a HP Celeron-based system last week from Costco, who was also offering the $400 Microsoft rebate. Total cost of the computer (after rebate) $150.
Our address: Castro Valley, CA.
Hmmm...if this pans out, he'll be canceling msn in a month.
Please don't speak for "Most of the Community". All I want to do is get some work done with it. While I am definately one to encourage someone to try Linux, I only encourage those WITH A BRAIN.
funny...the mechanics near my home charge between $65 and $80 dollars an hour. I don't remember ever getting a check from a newbie asking questions on irc...
Clueless newbies are one thing. Ungrateful clueless newbies who believe you owe them something are entirely different.
Off Topic: Linux Game Programming
on
Quake 1 GPL'ed
·
· Score: 1
What are some good introductory texts on game programming for Linux? By introductory, I mean tutorials that seek to teach technique, not how to code (I've been coding in C and C++ for almost ten years now).
Slashdot Mirror
Qualifier:
I work as a security/encryption sysadmin. I have a very strong background in math and system security. I've developed several encryption protocols that are in process of peer review. I've been a sysadmin for 7 years, and have programmed fr 15.
First off:
[trog@pain trog]$ ros www.paytrust.com
Netcraft: [11]www.paytrust.com is running Microsoft-IIS/4.0 on [12]NT4 or
Windows 98
www.paytrust.com: Server: Microsoft-IIS/4.0
Not to Microsoft bash, but IIS is extremely insecure. Due to fundemental problems with IIS, it really cannot be secured.
Secondly, with a bill payment that does direct money transfers, you are dealing with actual money, not credit cards. You have less legal protection against fraud here than if you use a credit card. IANAL, but I've worked with them in systems design.
Thirdly, there are really no industry-wide standard security practices. Visa can audit these bill payment companies, but they can only make suggestions, and their recommendations can be(and I have seen businesses who do) completely ignored, with no vendor ramifications.
Forth: A secure system is INCREDIBLY difficult to implement. It requires a vast amount of knowledge and experience that most sysadmin's simply don't have. Not that it can't be learned; it just takes a great deal of time and desire to learn. Add to that the proliferation of paper-MCSE's calling themselves security experts, and all the Internet startups who get their website up and lock the system down later, and you have a definate recepe for disaster.
Fifth: As a consumer, you have absolutely NO WAY of knowing if a site is truly secure. The CdUniverse fiasco happened because they stored their credit card numbers in their database PLAINTEXT. How pathetic.
In fact, most customers compromise their security when they connect to a secure site; the default 40-bit encryption from exportable browsers is trivial to crack.
I would stick to the old "check in the mail" until sysadmins start taking security seriously.
While your experience is great, the reason we are looking for perl programmers is:
1. Our existing code is all in perl,
2. It works, works fast, and works well
3. So why fix what ain't broken?
We are doing some work with PHP, but that's experimental, and may never enter production. If it does, it will work alongside our existing perl code; in the real world, you use the tool that works best for your application.
And I AM NOT a personell dept. - I am the sysadmin for the company. We ask for specific skills because those are the skills we require - the same as any other job in the world. And it is not some HR person that interviews you here; the geeks that you will be working with do that.
The biggest requirement for work here is that you must have that hacker/tinkerers spirit, and must jell well with the other people you are working with. Unfortunately, there is no real way to express that in a resume. While I don't doubt you have the technical background to do the work, the arrogance you just spewed out would kill you in the real world. Where I work, we are all a bunch of really skilled geeks, but we are also good friends.
The job offer is serious; we are looking for perl programmers and a webmaster in an all Linux/OpenBSD environment. If you are interested, let's see a link to the resume.
(I will not post on this subject further, as it seems to be a poor forum to do this)
This is absolutely true. I've been interviewing perl programmers and webmasters for the past month; NONE of them were qualified for the work. Competency can't really be taught; it's aquired through experimentation and experience.
Incidently, if you are a good perl programmer with Linux experience and wish to work at a great stert-up in Menlo Park, CA, reply to this thread with a link to your resume. I will contact you.
Please consider your two statements.
Even if we assume parents will usually make good decisions in these matters, where it really gets ugly is when the state decides what constitutes the master race.
and
I think the best uses of this would be to eliminate genetic traits that we can all agree are undesirable
and tell me what is the real difference between the two?
Fact of the matter is: all species engage in genetic selection, humans included. Every being wants the strongest possible offspring. Genetic knowledge just makes this a bit more precise.
ftp passwords are always sent plaintext, so yes, the NORMAL operation of an ftp server on any server on the Internet is on shakey ground. This is particularly true with a home DSL connection, as the box hosting the ftp server tends to be used for many different things (and thus, is more important to the user, and is more distructive when it is compromised.).
/bin/false (can't log in with those accounts, except via ftp - no shell access). Set up your ftp server in a chroot jail. Configure the ftp server to log every connection. While none of these things will prevent your box from being compromised, they all make things much more difficult for the 90% of crackers out there; those running canned scripts, with very little brains.
;-). My systems are port scanned an average of once every ten to twenty minutes, with stealth scan attempts almost as often. Every time I read about a new unix exploit on Bugtraq, I see crackers attempting it sever dozen times in my logs. If you have DSL, this is happening to you as well.
If you still want to use an ftp server, I suggest creating specific accounts for ftp usage only, who's shells are
Remember: The ip addresses of DSL and cable modems are well known to crackers. I monitor my home office (connected via DSL) with all sorts of various and sundry software
You have still COMPLELELY MISSED THE POINT.
Haven't you read the analysis of the DDoS attacks? The TFN and TFN2000 clients and servers can be configured to run on a port greater than 1024. That means, ANY ACCOUNT ON YOUR SYSTEM CAN RUN THE DDOS ATTACK.
Once one account is compromised, and shell access to the target system can be maintained, compromise of the root account is, in most cases, trivial.
ssh is a secure replacement for telnet. scp is a secure replacement for ftp. There are ssh clients for all common operating systems (though I've never found a scp tool for a non-unix system). You can still offer shell access to your box; just use a service that is more secure.
Your further ignorance, and hostility towards the correct solution further illustrates my point. Arrogance is no substitute for ability. The reason your box wasn't compromised (and it may very well have been, you could just be unaware of it) was pure luck. Nothing more.
telnet and ftp send all data back and forth in plaintext, INCLUDING YOUR PASSWORD. Any network sniffer between you and your box now has captured that account's password. Account compromised. Game over.
Your ignorance on this issue illustrated my point.
Problem is....YOU CAN'T educate the average Joe for security. It is far too involved and can't be solved with some magic pill or simple patch. Networked systems are horribly complex, with interactions on many different levels. It is better to leave the security in the hands of the few who have a passion for it.
Here's my solution: Have all ISP's providing DSL and cable service host the firewall for all their customers. Have them hire vigilant security minded sysadmins (there are few of them, but they are out there), who's only job is to keep the firewalled area secure. This way, Joe DSL doesn't have to worry about it all.
While this solves the problem for the ISP, it leaves Joe DSL without a way to run his own apache server, ftp server, telnet server, for hiw own low-volume stuff, even if he knows how to secure his machine.
If Joe DSL is running telnet or ftp, he MOST CERTAINLY doesn't know how to secure his machine.
As a sysadmin that works exclusively with security issues, I can tell you that the "personal firewall" is a worse solution than having no firewall at all. Security is a process; it is never ending, and requires a great deal of time and effort. Joe DSL is going to install that firewall, and think it will protect him forever. It creates a false sence of security.
Security cannot be left to people who don't constantly work to improve it. Joe DSL has neither the ability nor the desire to do this. Sadly, neither do most self-styled sysadmins.
You can't have it both ways. Either you aim for widespread acceptance of Linux (in which case, AOL must be embraced), or Linux remains the odd box in the server closet.
It is not only the illiterate users who use AOL. My fience, who is obtaining her teaching credentials, uses AOL on her iMac. She's very bright and intelligent, but when it comes to computers, she just wants to use them as a tool - nothing more. She has no desire to learn Linux. She just wants something that works, and will work without a minimum of fuss. This is what 90% of the people out there want.
When we are married later this year, that purple iMac is going to fit right into my home office, next to my Sparc, OpenBSD and Linux boxen. She'll keep her AOL, because that's what works for her.
If you really want the masses to use Linux, you can stand to learn a thing or two from that iMac.
Never use this airline again.
Recommend to my friends and business associates to not use this airline for any reason.
Hit them in the pocketbook...the only place that seems to matter to business anymore.
thats an easy one
Shut The Fuvk Up.
I'm telling you...kids these days...
The fact is that ANY server running on ANY OS without the proper cryptographic processing of the data before it is stored is the most important component of data security. If the data is stored in an SQL database unencrypted, if the server is compromised, the data belongs to the cracker.
An "e-commerce" server should have a two tier model for security. The first tier is Server security, which is what most of the uninformed are flaming about. The second tier, and MOST IMPORTANT, is data security. The data needs to be cryptographically processed in such a way that if the server is completely compromised, the data is completely useless to the cracker.
This takes a GREAT deal of skill and craft to successfully implement. Herein lies the problem: companies are so motivated to get the e-commerce thing going NOW that they leave themselves wide open.
The point of my post is that once they are encrypted properly, you can damn near store the encrypted card numbers in your .sig file - ain't no one gonna decrypt them.
There are several reasons for storing the credit card number on the server. Monthly billing, future purchases, etc. etc.
As for the processor, I can't disclose (under NDA)
The cards must be entered through a ssl encrypted form. Anyone who would enter their credit card info in an insecure form deserves to be ripped off.
This response was obviously from someone who doesn't deal with either cryptography or "e-commerce" (I HATE that buzzword).
Secure cc transactions require a multi-layered cryptographic approach. The protocol used in the receiving of the cc numbers is much different then what is done when you store the numbers. If you a)process a credit card number with a cryptographically secure PRNG (cc's are VERY PREDICTIBLE), sign treated cc numbers before encrypting, and use an asymetric encryption algorithm with large keys that has shown to be strong (and the server only has the public key stored on it), YOU CAN SAFELY STORE THE CREDIT CARD NUMBER ON THE SERVER. Only the credit card processor has the private key, and the cc numbers should NEVER be decrypted on a system connected to the Internet.
If a server is set up this way, and the entire credit card database is downloaded to some script kiddie's system, they are still useless. I've never met a script kiddie that could decrypt randomized credit card numbers with 2048-bit RSA keys.
The problem is that the proper use and implementation of cryptography is amazingly difficult. I've been dealing with encryption for five years, and e-commerce sites for about two years; even most "Unix Guru's" don't get it right. It takes a lot of time and specialized knowledge.
You are refering to a symmetric algorithm (I am inferring this from your reference to ssl, which requires a symetric algorithm). In this case, yes, you are correct; however, (if implemented correctly), ssl will encrypt a unique session key, that changes with each new connection. With a unique session key, you still cannot decrypt the data, as it is encrypted with both the session key and the symetric cipher.
The article appears (at least to me) to be refering to public key encryption, such as used in PGP. These protocols make use of asymetric algorithms, which require two unique keys - a public and private. You can encrypt messages with either key, but you cannot derive on key from the other.
The key to security here is having only the public key available on a system connected to the Internet. While you still must guard against sideband attacks, this makes a brut force attack against the crypto infeasable.
Yes, I am suggesting that the data is re-encrypted and passed to a secured vault server. And yes, it is a very, very good idea.
It appears that the article is discussing a flaw in the implimentation of an asymetrical algorithm, such as ElGamel or RSA. Real easy solution folks - the server that is actually taking credit card numbers should only have the public key stored on it. There is no need for the private key to be on any public accessable system, as the decryption of the card data is done only by the card processor, which is never done on a system connected to the Internet.
You also must introduce randomness to the credit card data before encrypting, because the regularity of credit card numbers allows a cracker to make a known-plaintext attack.
I've been dealing with security and encryption with e-commerse for about two years. Anyone who would set up a system like that discussed in the article is a rank amateur and a fool.
The article is a bunch of bullshit.
My room-mate just bought a HP Celeron-based system last week from Costco, who was also offering the $400 Microsoft rebate. Total cost of the computer (after rebate) $150.
Our address: Castro Valley, CA.
Hmmm...if this pans out, he'll be canceling msn in a month.
Please don't speak for "Most of the Community". All I want to do is get some work done with it. While I am definately one to encourage someone to try Linux, I only encourage those WITH A BRAIN.
*nix is not your grandmother's OS.
funny...the mechanics near my home charge between $65 and $80 dollars an hour. I don't remember ever getting a check from a newbie asking questions on irc...
Clueless newbies are one thing. Ungrateful clueless newbies who believe you owe them something are entirely different.
I agree with the ASL recommendation. Their systems have worked well for me.
Oh shit...please say that you aren't serious.
I've never met anyone that stupid.
What are some good introductory texts on game programming for Linux? By introductory, I mean tutorials that seek to teach technique, not how to code (I've been coding in C and C++ for almost ten years now).