The interesting question is: What is the optimal hardware for running Doom 3 on a GNU/Linux system? I haven't played a game since RtCW, and I want to buy a new system to play Doom 3 on GNU/Linux. I know nothing about the current state of hardware support for various high-end graphics cards on GNU/Linux.
Sounds almost like Robert Morris jr. from back in those days when the US was still a reasonable country. I'm sure Mr. Morris took out a far bigger fraction of the Internet than Mr. German did. No death penalty for that stuff back in good ol' 88.
I wonder if they calculate a new average after cutting off the upper extremes. And then cap the above average guys again, and calculate a new average. And so on...
... for stuff like this. The annual Totally worthless, 100% hack value, too-much-geek-time-to-spare prize. And the 6502 BASIC TCP/IP stack-based web server should be the first winner.
This is no bug, but a cover-up of a nanotech experiment gone wrong. Call Bill Joy, and pray that those iron-eating nano robots won't reach the surface.
And we would have some hell of a time if we were to administer a 500+ computers network used by security-unconscious consultants who needed total control of their machines in order to have their jobs done.
Be my guest: Shut off your firewall. I prefer having mine up-and-running. Thank you.
My experience is different than yours. I've spent the two last years giving courses and lectures on exactly these topics to approximately 700 programmers in everything from small, 10-person companies, via banks, to large, international consulting companies. Far less then half of these experienced developers knew about SQL Injection. Next to none fully understood Cross-site-Scripting-based session hijacking.
I used to spend some late evenings looking for symptomes of SQL Injection and Cross-site Scripting (two of the vulnerabilities most easily detected from the outside without doing something really intrusive). I have a list of 170 sites, including banks and web shops that have symptoms on these problems. That's about half of the sites I've checked.
I've skimmed book upon book on "building E-commerce solutions", and every single one of them contains examples with unintended security holes in them. Even books on web application security contains examples that are vulnerable.
So, I strongly disagree with you. In my experience, most web application programmers know next to nothing about these problems.
I don't know who this "nordicfrost" is in person, but his home page is the index page of VG, the leading tabloid paper in Norway. Also, the link to "we have set up... here in English" points to the same paper. I hereby assume that "nordicfrost" works for VG.
This auto-slashdotting appears the day after several Norwegian papers accuse the main tabloid competitor of VG for cheating in the national "we-have-the-most-popular-web-site-in-Norway". The competitor had made a popular Norwegian game site give all its web hits to them.
Some people may think that auto-slashdotting is more of a cheat, but as the Jon Johansen case shows, what "some people" may think is not necessarily what counts. Money rule.
If I understand correctly, pay-per-view isn't the most common method to get income from web based advertisement anymore. It's pay-per-click or even pay-per-sale.
People who (like me) filter web ads are the ones who are annoyed by them. Annoyed to the point that they won't click on any ad, no matter how tempting it is. By forcing those people to watch the ads, the result is, at least for me, that I refuse to visit the site at all (unless Google does it, I guess). We can live without most web sites.
Also, I do not understand why they define people as thieves because they do not want to see the ads. What about TV commercial breaks? I know that _many_ people use the breaks to go peeing, make a sandwich, or even zap through the other TV channels. Are they thieves? Should they stop watching the movie if they do not also faithfully watch the commercials?
I think the ones advertising on TV realize that a certain amount of the viewers will not see the ads. And that a certain amount of those will _never_ see any ads. I can't see why it should be any different on the web.
I couldn't close my account, because it had $1.95 on it. And I could not remove those money, as the PayPal people do not transfer money internationally unless the amount is at least $25.00.
Oh, well. I did at least remove my credit card info. If you're a bad-guy and happen to pick up my $1.95, please close the account afterwards.;-)
The web page talks about the 90% of documents in the world that are still on paper only. Now I really hope that everybody understand that using DjVu alone to webify these documents will be of little value. How do you expect to find those documents? Will Google be able to index images?
Scanned documents on the web will have to be included in web pages that contain reasonable keywords and extracts from the texts. Scanning, compressing and commenting may actually be more work than keying in the entire document, so most people will probably just skip the commenting.
But heck, nobody seem to remember that the web was about content, not layout, so I'm sure DjVu will be warmly welcomed.
To quote the web page: "AIDE (Advanced Intrusion Detection Environment) is a free replacement for Tripwire. It does the same things as the semi-free Tripwire and more."
I must agree. I've been running Crack for both Unix (Solaris and GNU/Linux) and Windows NT where I work, and it's amazing how many passwords were found just in a few minutes. Crack is an extremely cool program.
[Heh, I wrote the following text for some friends about a week ago. Fits perfectly here.:) ]
How many sites, servers or systems do you log into regularly? On how
many sites, servers or systems have you registered yourself with a
user name and password? Quite some number, or what? Now; how many
different passwords did you use? Of course you've been told many
times to use different passwords everywhere. I keep wondering what
idiot invented that impossible rule; it goes without saying that you
need to reuse your passwords, unless you have a computer in your
brain.
What's my point? Let's say one of the administrators of one of those
sites is not as honest as it first seemed, and takes a peek into the
password database. Or let's say that someone cracks into that
database and gets hold of all the passwords. What could that person,
given your often used password, do on all the other sites you visit?
Would you like someone else to speak for you? To buy for you? To
sell your stocks? To use the encyclopedia you pay for? To read your
mail? Probably not. And it doesn't have to be that way if all web
developers out there obey the following, simple rule:
Never store clear text passwords.
You do not need to keep a user's password to be able authenticate her.
To repeat: Neither you, nor your web server, need to store any user's
password. The technology is ages old: You pass the initial password
through a one way hash function, and store the garbled password in
your database. Whenever the user wants to log in, you take the user
provided password, pass it through the same hashing function, and
compare the result with whatever you have in your database.
I guess some of you don't know what hash functions are, so here's a
short intro: Hash functions, or message digests, are one way functions
that take a text as input, and produce a signature based on the text.
Calling the function "one way" means that, given a signature, it is
impossible to get back to the original text. A good hash function
also makes it extremely hard to come up with a different text that
yields the same signature.
Several hash functions exist. The password file on Unix traditionally
uses a DES based hash function, known as crypt, to hide passwords.
Windows NT uses MD4 for passwords. I would suggest you use a widely
available function known as MD5. It is considered more secure than
both crypt and MD4. PHP has the string function md5, Java has the
java.security.MessageDigest class which provides MD5, Perl has an MD5
module, and I guess you'll be able to find some component for
ASP/VBscript too.
If you've ever read about password hashing, you may have run into the
term "salting". We may use salting to make sure two hashed password
are different even if they come from the same password. If you choose
"beer" as your password, and have access to the hashed passwords, we
don't want you to recognize another "beer" drinker among the users.
You may think that requiring unique passwords is a solution, but it is
not: If you register somewhere, and learn that the password you chose
is already taken, you may run thru the users and test with the
occupied password until you reach the owner. We do _not_ want unique
passwords.
A common strategy for salting is to combine the user name and password
into a new string, eg. with a line break in between, and pass that
string through the hash function. Of course you will need to redo the
combination when you verify the password.
What follows is a simple example in PHP. We provide one function for
storing the hashed password, and one for authenticating a user. Of
course you will need to implement the database functions yourself.
# Given a user name and a clear text password, calculate the
# salted, hashed password.
function getHashedPassword($username, $password) {
return strtoupper(md5($username . "\n" . $password));
}
# Given a user name and a clear text password, calculate the
# salted, hashed password, and store it in a database.
function storeInitialPassword($username, $password) {
$hashedPassword = getHashedPassword($username, $password);
# Save the hashed password in the database.
setHashedPasswordForUser($username, $password);
}
# Given a user name and a clear text password, calculate the
# salted, hashed password, and compare it to the one in the
# database. Return 1 if the user is successfully verified,
# 0 if verification failed (bad password).
function verifyPassword($username, $password) {
# Fetch the hashed password from the database.
$hashedPassword = getHashedPasswordForUser($username);
# Salt and hash the provided password.
$hashedProvidedPassword = getHashedPassword($username, $password);
# If the two hashed passwords are equal, everything is fine.
if ($hashedProvidedPassword == $hashedPassword)
return 1;
# The hashed passwords didn't match. Invalid password.
return 0;
}
As the example shows, storing hashed passwords is almost as simple as
storing clear text password. And it is a whole lot more safe. If you
choose to hash the passwords on the site you develop, you should
consider mentioning it on a "privacy policy" page. Advanced users
will appreciate it, and understand that you take security seriously.
Slashdot Mirror
Hey, attrition, did you make a note on that?
The interesting question is: What is the optimal hardware for running Doom 3 on a GNU/Linux system? I haven't played a game since RtCW, and I want to buy a new system to play Doom 3 on GNU/Linux. I know nothing about the current state of hardware support for various high-end graphics cards on GNU/Linux.
Sounds almost like Robert Morris jr. from back in those days when the US was still a reasonable country. I'm sure Mr. Morris took out a far bigger fraction of the Internet than Mr. German did. No death penalty for that stuff back in good ol' 88.
There's a patent on XBox viruses, so you probably won't see any until the patent expires in 2018.
I wonder if they calculate a new average after cutting off the upper extremes. And then cap the above average guys again, and calculate a new average. And so on...
... the only winning move is not to play."
... for stuff like this. The annual Totally worthless, 100% hack value, too-much-geek-time-to-spare prize. And the 6502 BASIC TCP/IP stack-based web server should be the first winner.
This is no bug, but a cover-up of a nanotech experiment gone wrong. Call Bill Joy, and pray that those iron-eating nano robots won't reach the surface.
I had to buy a sound card.
And we would have some hell of a time if we were to administer a 500+ computers network used by security-unconscious consultants who needed total control of their machines in order to have their jobs done.
Be my guest: Shut off your firewall. I prefer having mine up-and-running. Thank you.
My experience is different than yours. I've spent the two last years giving courses and lectures on exactly these topics to approximately 700 programmers in everything from small, 10-person companies, via banks, to large, international consulting companies. Far less then half of these experienced developers knew about SQL Injection. Next to none fully understood Cross-site-Scripting-based session hijacking.
I used to spend some late evenings looking for symptomes of SQL Injection and Cross-site Scripting (two of the vulnerabilities most easily detected from the outside without doing something really intrusive). I have a list of 170 sites, including banks and web shops that have symptoms on these problems. That's about half of the sites I've checked.
I've skimmed book upon book on "building E-commerce solutions", and every single one of them contains examples with unintended security holes in them. Even books on web application security contains examples that are vulnerable.
So, I strongly disagree with you. In my experience, most web application programmers know next to nothing about these problems.
I don't know who this "nordicfrost" is in person, but his home page is the index page of VG, the leading tabloid paper in Norway. Also, the link to "we have set up ... here in English" points to the same paper. I hereby assume that "nordicfrost" works for VG.
This auto-slashdotting appears the day after several Norwegian papers accuse the main tabloid competitor of VG for cheating in the national "we-have-the-most-popular-web-site-in-Norway". The competitor had made a popular Norwegian game site give all its web hits to them.
Some people may think that auto-slashdotting is more of a cheat, but as the Jon Johansen case shows, what "some people" may think is not necessarily what counts. Money rule.
Searching for Kathleen Fent on Google images gives just two pictures: One joystick, and a security lock. Could someone please explain the symbols?
If I understand correctly, pay-per-view isn't the most common method to get income from web based advertisement anymore. It's pay-per-click or even pay-per-sale.
People who (like me) filter web ads are the ones who are annoyed by them. Annoyed to the point that they won't click on any ad, no matter how tempting it is. By forcing those people to watch the ads, the result is, at least for me, that I refuse to visit the site at all (unless Google does it, I guess). We can live without most web sites.
Also, I do not understand why they define people as thieves because they do not want to see the ads. What about TV commercial breaks? I know that _many_ people use the breaks to go peeing, make a sandwich, or even zap through the other TV channels. Are they thieves? Should they stop watching the movie if they do not also faithfully watch the commercials?
I think the ones advertising on TV realize that a certain amount of the viewers will not see the ads. And that a certain amount of those will _never_ see any ads. I can't see why it should be any different on the web.
How about this one, then:
It's just a GET request, but if the site suffers from SQL Injection problems, which many sites do, stuff may be deleted from the database.
I couldn't close my account, because it had $1.95 on it. And I could not remove those money, as the PayPal people do not transfer money internationally unless the amount is at least $25.00.
;-)
Oh, well. I did at least remove my credit card info. If you're a bad-guy and happen to pick up my $1.95, please close the account afterwards.
and THANK YOU!
That quote belongs to Andrew S. Tanenbaum of Minix fame.
Let's just hope they don't knock the comet into
a collission c(o)urse with our favorite planet.
The web page talks about the 90% of documents in the world that are still on paper only. Now I really hope that everybody understand that using DjVu alone to webify these documents will be of little value. How do you expect to find those documents? Will Google be able to index images?
Scanned documents on the web will have to be included in web pages that contain reasonable keywords and extracts from the texts. Scanning, compressing and commenting may actually be more work than keying in the entire document, so most people will probably just skip the commenting.
But heck, nobody seem to remember that the web was about content, not layout, so I'm sure DjVu will be warmly welcomed.
Who needs Tripwire when we have AIDE?
To quote the web page: "AIDE (Advanced Intrusion Detection Environment) is a free replacement for Tripwire. It does the same things as the semi-free Tripwire and more."
Check it out!
http://www.cs.tut.fi/~rammer/aide.html
I must agree. I've been running Crack for both Unix (Solaris and GNU/Linux) and Windows NT where I work, and it's amazing how many passwords were found just in a few minutes. Crack is an extremely cool program.
c 50-faq.html
http://www.users.dircon.co.uk/~crypto/download/
I don't remember where I found the NT port of Crack. Sorry.
I will correct you. The output from the md5 function consists of hexadecimal digits. I use strtoupper because i like upper case hex digits.
Yes. Thank you.
[Heh, I wrote the following text for some friends about a week ago. Fits perfectly here. :) ]
How many sites, servers or systems do you log into regularly? On how
many sites, servers or systems have you registered yourself with a
user name and password? Quite some number, or what? Now; how many
different passwords did you use? Of course you've been told many
times to use different passwords everywhere. I keep wondering what
idiot invented that impossible rule; it goes without saying that you
need to reuse your passwords, unless you have a computer in your
brain.
What's my point? Let's say one of the administrators of one of those
sites is not as honest as it first seemed, and takes a peek into the
password database. Or let's say that someone cracks into that
database and gets hold of all the passwords. What could that person,
given your often used password, do on all the other sites you visit?
Would you like someone else to speak for you? To buy for you? To
sell your stocks? To use the encyclopedia you pay for? To read your
mail? Probably not. And it doesn't have to be that way if all web
developers out there obey the following, simple rule:
Never store clear text passwords.
You do not need to keep a user's password to be able authenticate her.
To repeat: Neither you, nor your web server, need to store any user's
password. The technology is ages old: You pass the initial password
through a one way hash function, and store the garbled password in
your database. Whenever the user wants to log in, you take the user
provided password, pass it through the same hashing function, and
compare the result with whatever you have in your database.
I guess some of you don't know what hash functions are, so here's a
short intro: Hash functions, or message digests, are one way functions
that take a text as input, and produce a signature based on the text.
Calling the function "one way" means that, given a signature, it is
impossible to get back to the original text. A good hash function
also makes it extremely hard to come up with a different text that
yields the same signature.
Several hash functions exist. The password file on Unix traditionally
uses a DES based hash function, known as crypt, to hide passwords.
Windows NT uses MD4 for passwords. I would suggest you use a widely
available function known as MD5. It is considered more secure than
both crypt and MD4. PHP has the string function md5, Java has the
java.security.MessageDigest class which provides MD5, Perl has an MD5
module, and I guess you'll be able to find some component for
ASP/VBscript too.
If you've ever read about password hashing, you may have run into the
term "salting". We may use salting to make sure two hashed password
are different even if they come from the same password. If you choose
"beer" as your password, and have access to the hashed passwords, we
don't want you to recognize another "beer" drinker among the users.
You may think that requiring unique passwords is a solution, but it is
not: If you register somewhere, and learn that the password you chose
is already taken, you may run thru the users and test with the
occupied password until you reach the owner. We do _not_ want unique
passwords.
A common strategy for salting is to combine the user name and password
into a new string, eg. with a line break in between, and pass that
string through the hash function. Of course you will need to redo the
combination when you verify the password.
What follows is a simple example in PHP. We provide one function for
storing the hashed password, and one for authenticating a user. Of
course you will need to implement the database functions yourself.
# Given a user name and a clear text password, calculate the
# salted, hashed password.
function getHashedPassword($username, $password) {
return strtoupper(md5($username . "\n" . $password));
}
# Given a user name and a clear text password, calculate the
# salted, hashed password, and store it in a database.
function storeInitialPassword($username, $password) {
$hashedPassword = getHashedPassword($username, $password);
# Save the hashed password in the database.
setHashedPasswordForUser($username, $password);
}
# Given a user name and a clear text password, calculate the
# salted, hashed password, and compare it to the one in the
# database. Return 1 if the user is successfully verified,
# 0 if verification failed (bad password).
function verifyPassword($username, $password) {
# Fetch the hashed password from the database.
$hashedPassword = getHashedPasswordForUser($username);
# Salt and hash the provided password.
$hashedProvidedPassword = getHashedPassword($username, $password);
# If the two hashed passwords are equal, everything is fine.
if ($hashedProvidedPassword == $hashedPassword)
return 1;
# The hashed passwords didn't match. Invalid password.
return 0;
}
As the example shows, storing hashed passwords is almost as simple as
storing clear text password. And it is a whole lot more safe. If you
choose to hash the passwords on the site you develop, you should
consider mentioning it on a "privacy policy" page. Advanced users
will appreciate it, and understand that you take security seriously.