Bitcoin Forum
December 09, 2016, 09:43:16 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 [50] 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 »
  Print  
Author Topic: [Emergency ANN] Bitcoinica site is taken offline for security investigation  (Read 201841 times)
BTC_Bear
B4 Foundation
VIP
Sr. Member
*
Offline Offline

Activity: 364


Best Offense is a Good Defense


View Profile WWW
May 18, 2012, 04:21:06 PM
 #981

You are also assuming that there have not already been rainbow tables made for simple passwords.

Corporations have been enthroned, An era of corruption in high places will follow and the money power will endeavor to prolong its reign by working on the prejudices of the people until wealth is aggregated in a few hands and the Republic is destroyed. ~Abe Lincoln 1ApJdWUdSWYw8n8HEATYhHXA9EYoRTy7c4
1481319796
Hero Member
*
Offline Offline

Posts: 1481319796

View Profile Personal Message (Offline)

Ignore
1481319796
Reply with quote  #2

1481319796
Report to moderator
1481319796
Hero Member
*
Offline Offline

Posts: 1481319796

View Profile Personal Message (Offline)

Ignore
1481319796
Reply with quote  #2

1481319796
Report to moderator
1481319796
Hero Member
*
Offline Offline

Posts: 1481319796

View Profile Personal Message (Offline)

Ignore
1481319796
Reply with quote  #2

1481319796
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481319796
Hero Member
*
Offline Offline

Posts: 1481319796

View Profile Personal Message (Offline)

Ignore
1481319796
Reply with quote  #2

1481319796
Report to moderator
1481319796
Hero Member
*
Offline Offline

Posts: 1481319796

View Profile Personal Message (Offline)

Ignore
1481319796
Reply with quote  #2

1481319796
Report to moderator
1481319796
Hero Member
*
Offline Offline

Posts: 1481319796

View Profile Personal Message (Offline)

Ignore
1481319796
Reply with quote  #2

1481319796
Report to moderator
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
May 18, 2012, 04:37:16 PM
 #982

You are also assuming that there have not already been rainbow tables made for simple passwords.

That is the point of salt.

32 bit salt = 4 billion permutations of every password.
So to pre-compute the 1 million most commonly used passwords would require ~ 5 quadrillion operations.

bcrypt uses hundreds or thousands of rounds to hash the password.  Throughput even on high end GPU is slow for bcrypt.  While a 5970 might be able to process ~8 billion MD5 hashes per second it is in the <10,000 bcrypt (2000 round) passwords per second.

So you are talking ~ 5 quadrillion  /10,000 /60 /60 /24 /365 = 158,000 GPU years (i.e. 1x 5970 for 158,000 years or 158,000 5970s for 1 year or some combination).

Of course even if hackers were stupid enough to waste the billions of dollars that would cost all that pre-computed wealth could be erased by simply going to a 64 bit salt. Smiley


DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
May 18, 2012, 04:49:15 PM
 #983

Not really. I'm sure there's CUDA code and openCL code to dramatically improve on that. (About x10 last time I checked for a single mid-range GPU vs a multicore CPU)

Long complex passwords simply can't be brute forced via any cryptographically secure key derivative function (like bcrypt) in any useful amount of time.  

10x sounds impressive until you realize that means "only" decades instead of centuries.  One also has to consider the value of the computing time.  Spending $10,000 in computing time to steal $500 isn't a good way to become rich.


muyuu
Donator
Legendary
*
Offline Offline

Activity: 924



View Profile
May 18, 2012, 04:53:46 PM
 #984

Not really. I'm sure there's CUDA code and openCL code to dramatically improve on that. (About x10 last time I checked for a single mid-range GPU vs a multicore CPU)

Long complex passwords simply can't be brute forced via any cryptographically secure key derivative function (like bcrypt). 

10x sounds impressive until you realize that means "only" 1000s of years instead of 10s of thousands of years. 

Sure, we're talking about short, weak passwords. Bcrypt is slow to bruteforce, doesn't mean it isn't a concern if the password isn't strong enough.

Nitpicking over the obvious here, really.

GPG ID: 7294199D - OTC ID: muyuu (470F97EB7294199D)
forum tea fund BTC 1Epv7KHbNjYzqYVhTCgXWYhGSkv7BuKGEU DOGE DF1eTJ2vsxjHpmmbKu9jpqsrg5uyQLWksM CAP F1MzvmmHwP2UhFq82NQT7qDU9NQ8oQbtkQ
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
May 18, 2012, 04:58:02 PM
 #985

Well maybe you should read before you respond.

Your respond to a most that said long passwords would take years to break saying "not really" and then now say "we" (which I guess means only you) are talking about short weak passwords.  Of course it was already pointed out that  bitcoinica can determine how strong the password are so verification of accounts w/ strong passwords presents no security risk.

MrTeal
Legendary
*
Offline Offline

Activity: 1246


View Profile
May 18, 2012, 04:59:27 PM
 #986

Not really. I'm sure there's CUDA code and openCL code to dramatically improve on that. (About x10 last time I checked for a single mid-range GPU vs a multicore CPU)

Long complex passwords simply can't be brute forced via any cryptographically secure key derivative function (like bcrypt). 

10x sounds impressive until you realize that means "only" 1000s of years instead of 10s of thousands of years. 

Sure, we're talking about short, weak passwords. Bcrypt is slow to bruteforce, doesn't mean it isn't a concern if the password isn't strong enough.

Nitpicking over the obvious here, really.

What's considered a short, weak password?
muyuu
Donator
Legendary
*
Offline Offline

Activity: 924



View Profile
May 18, 2012, 05:08:54 PM
 #987

Not really. I'm sure there's CUDA code and openCL code to dramatically improve on that. (About x10 last time I checked for a single mid-range GPU vs a multicore CPU)

Long complex passwords simply can't be brute forced via any cryptographically secure key derivative function (like bcrypt). 

10x sounds impressive until you realize that means "only" 1000s of years instead of 10s of thousands of years. 

Sure, we're talking about short, weak passwords. Bcrypt is slow to bruteforce, doesn't mean it isn't a concern if the password isn't strong enough.

Nitpicking over the obvious here, really.

What's considered a short, weak password?

https://en.wikipedia.org/wiki/Password_strength

Sorry to delegate on Wikipedia but I really have used way too much time in this thread.

Typical rules of thumb include using 8+ characters, mixed capitalisation and both numbers and alphabet characters. (See the entropy table in the article linked).

GPG ID: 7294199D - OTC ID: muyuu (470F97EB7294199D)
forum tea fund BTC 1Epv7KHbNjYzqYVhTCgXWYhGSkv7BuKGEU DOGE DF1eTJ2vsxjHpmmbKu9jpqsrg5uyQLWksM CAP F1MzvmmHwP2UhFq82NQT7qDU9NQ8oQbtkQ
jixapori
Jr. Member
*
Offline Offline

Activity: 46


View Profile
May 18, 2012, 05:18:16 PM
 #988

for those of you taking notes, there is no good reason for anyone to transmit a clear-text password, strong or weak, to any web site. one is supposed to use zero-knowledge proofs for this, this also avoids possible dictionary attacks
BTC_Bear
B4 Foundation
VIP
Sr. Member
*
Offline Offline

Activity: 364


Best Offense is a Good Defense


View Profile WWW
May 18, 2012, 05:20:19 PM
 #989

You are also assuming that there have not already been rainbow tables made for simple passwords.

That is the point of salt.

32 bit salt = 4 billion permutations of every password.
So to pre-compute the 1 million most commonly used passwords would require ~ 5 quadrillion operations.

bcrypt uses hundreds or thousands of rounds to hash the password.  Throughput even on high end GPU is slow for bcrypt.  While a 5970 might be able to process ~8 billion MD5 hashes per second it is in the <10,000 bcrypt (2000 round) passwords per second.

So you are talking ~ 5 quadrillion  /10,000 /60 /60 /24 /365 = 158,000 GPU years (i.e. 1x 5970 for 158,000 years or 158,000 5970s for 1 year or some combination).

Of course even if hackers were stupid enough to waste the billions of dollars that would cost all that pre-computed wealth could be erased by simply going to a 64 bit salt. Smiley




Yes it isn't easy and can be expensive: If you start Now.

Let me ask: How long has bcrypt been around?  Do you think the first 1 Million Easy Passwords haven't already been tabled?

Protecting the DB is of the utmost importance, maybe more importantly, force strong passwords on registration.

An article of possible interest.

http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html  


Corporations have been enthroned, An era of corruption in high places will follow and the money power will endeavor to prolong its reign by working on the prejudices of the people until wealth is aggregated in a few hands and the Republic is destroyed. ~Abe Lincoln 1ApJdWUdSWYw8n8HEATYhHXA9EYoRTy7c4
ashleyconnor
Jr. Member
*
Offline Offline

Activity: 38


View Profile
May 18, 2012, 05:22:49 PM
 #990

You are also assuming that there have not already been rainbow tables made for simple passwords.

That is the point of salt.

32 bit salt = 4 billion permutations of every password.
So to pre-compute the 1 million most commonly used passwords would require ~ 5 quadrillion operations.

bcrypt uses hundreds or thousands of rounds to hash the password.  Throughput even on high end GPU is slow for bcrypt.  While a 5970 might be able to process ~8 billion MD5 hashes per second it is in the <10,000 bcrypt (2000 round) passwords per second.

So you are talking ~ 5 quadrillion  /10,000 /60 /60 /24 /365 = 158,000 GPU years (i.e. 1x 5970 for 158,000 years or 158,000 5970s for 1 year or some combination).

Of course even if hackers were stupid enough to waste the billions of dollars that would cost all that pre-computed wealth could be erased by simply going to a 64 bit salt. Smiley

2^(workfactor) if I recall correctly. FPGAs can be used successfully against BCrypt, despite it's security. Not to say BCrypt is insecure, like you said it's capable of thwarting rainbow tables and most brute-force attacks.

Scrypt is an interesting alternative though. It has a max-space factor bringing hardware costs into the equation.
muyuu
Donator
Legendary
*
Offline Offline

Activity: 924



View Profile
May 18, 2012, 05:37:34 PM
 #991

Not really. I'm sure there's CUDA code and openCL code to dramatically improve on that. (About x10 last time I checked for a single mid-range GPU vs a multicore CPU)

Long complex passwords simply can't be brute forced via any cryptographically secure key derivative function (like bcrypt) in any useful amount of time.  

10x sounds impressive until you realize that means "only" decades instead of centuries.  One also has to consider the value of the computing time.  Spending $10,000 in computing time to steal $500 isn't a good way to become rich.

Please don't make me waste more of my Friday afternoon over absurd arguments.

This is the post I replied to:

muyuu, your argument about bruteforcing the passwords is not entirely correct, because Bitcoinica uses bcrypt. This means that difficulty of cracking even simplier passwords rises dramatically (from minutes to days), and somewhat complex (7+ chars or so) passwords are safe, because it would take years to brute them. That's why I think the a password should be primary method of verification in the claim process.

He says that my argument is not correct, but it is. Difficulty rises dramatically as he said, but that doesn't mean that "even the simplest" passwords cannot be bruteforced.

That's what I meant with "not really." Yes, bcrypt makes less entropy necessary, but still a decent amount of entropy is required. Trivial passwords are still beaten by dictionary attacks and brute-forcing.

I'm absolutely convinced that many Bitcoinica users have weak enough passwords such that they have been broken already, bcrypt or not. Which is why they really cannot afford to temporarily reopen the site.

This is the point, not if you can crack away 1000 bcrypt trials per second or 1E+6. Given a trivial enough password, either would do. Bitcoinica didn't enforce strong passwords, that's a fact.

GPG ID: 7294199D - OTC ID: muyuu (470F97EB7294199D)
forum tea fund BTC 1Epv7KHbNjYzqYVhTCgXWYhGSkv7BuKGEU DOGE DF1eTJ2vsxjHpmmbKu9jpqsrg5uyQLWksM CAP F1MzvmmHwP2UhFq82NQT7qDU9NQ8oQbtkQ
MrTeal
Legendary
*
Offline Offline

Activity: 1246


View Profile
May 18, 2012, 05:39:49 PM
 #992

What's considered a short, weak password?

https://en.wikipedia.org/wiki/Password_strength

Sorry to delegate on Wikipedia but I really have used way too much time in this thread.

Typical rules of thumb include using 8+ characters, mixed capitalisation and both numbers and alphabet characters. (See the entropy table in the article linked).

Feel free to correct me on this, it's not my area of expertise. 8+ characters would be ideal, but with a good salt each password would have to be cracked individually, and the attacker would not know from the hashes they stole which ones are insecure.

Thus, with a strong salt making anything but huge rainbow tables ineffective, while some users might have relatively weak passwords that could be solved in reasonable amounts of time, the attackers wouldn't know which they are and would have to attack the entire DB looking for them. How long would it take with a reasonable GPU farm (say 4 5970s) a 6 character case sensitive Latin alphabet password?
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
May 18, 2012, 05:45:27 PM
 #993

Yes it isn't easy and can be expensive: If you start Now.

Let me ask: How long has bcrypt been around?  Do you think the first 1 Million Easy Passwords haven't already been tabled?

bcrypt has been around since 1999.  The length of time is kinda immaterial though because of Moore's law. If you started 12 years ago due to Moore's law the amount of work completed in those first 12 years would only be equal to 2 years if starting today (same budget/space/resources).

You can't ask something like "has 1 million passwords been rainbow tabled".

There are 3 inputs for bcrypt
the plain text password
the work level (# of rounds)
the salt

So even to build a rainbow table of 1 million passwords you would need to pick a work level and salt value.To have any practical value you will need multiple tables one for every salt value and work level combination.   Obviously both of those parameters are nearly infinite so you would need to select some constraint.  

Say you limited your project ot all 32 bit salts and work levels <= 20.  That means not 1 rainbow table but 80 billion rainbow tables (each containing 1 million passwords and their hash).  So you build a farm with a million or so GPU and at ~$1B or so in cost and a decade of time you have precomputed all 1 million most commonly used passwords, for all 32 bit salts, and work level <=20.  The disk space alone would be (assume 70 bytes per record) 70 * 1M * 20 * 2^32 = ~ 6000 Petabytes (6 EB).  If stored with no redundancy or backup on 2TB drives would require 3 million drives.  RAID & off site backups would more than double that.  To put that into perspective the entire human race's stored data (in all forms) is estimated at ~300 Exabytes.

Despite all that work if the website uses a >32 bit salt or work level >20 it is worthless work.  Given Moore's law is continually increasing over a long enough timeline every site will be using work level > 20 and salt > 32 bit rending your work obsolete.

If this seems hard to overcome.  That is the entire point.  By using per round salting, unique salt per user, and a modifiable work level the whole "point" of bcrypt (and other similar algorithms) was to make precomputation impossible.
BTC_Bear
B4 Foundation
VIP
Sr. Member
*
Offline Offline

Activity: 364


Best Offense is a Good Defense


View Profile WWW
May 18, 2012, 06:03:49 PM
 #994

D&T

Maybe I am coming from this wrong. The 'attackers' have the DB with the hashes, correct?  And they have the codebase, I would assume.

They have what they need, imo. For easy passwords.

I'm not arguing that it isn't hard, it is.

I am also not saying this is possible for a normal organization.

But there are organizations out there that can do it.

But then again, it probably wouldn't take that long to go around typing in <password> into websites to get a hit and save all those calculations.

Lets take what we know: bcrypt is good but it has a cost to being good. The stronger a site makes it based on the number of users, the more cost there is to the site owners in calculations. Given what is known about bicoinica we could make some assumptions there. (ps. Using one's own use of bcrypt against a company is a form of financial attack by forcing the company to have more resources to calculate the logins).

Or if I had 1 person logging in the # of rounds can be high for little cost, but if I had 5 Million people logging in, then the # of rounds becomes a financial question in terms of hardware.


In anycase, whoever used the password password will have some issues claiming his probably thousands of coins from bitcoinica because there will be more than one claimant.





Corporations have been enthroned, An era of corruption in high places will follow and the money power will endeavor to prolong its reign by working on the prejudices of the people until wealth is aggregated in a few hands and the Republic is destroyed. ~Abe Lincoln 1ApJdWUdSWYw8n8HEATYhHXA9EYoRTy7c4
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
May 18, 2012, 06:07:36 PM
 #995

Or if I had 1 person logging in the # of rounds can be high for little cost, but if I had 5 Million people logging in, then the # of rounds becomes a financial question in terms of hardware.
If you have 5 million users, you should have dedicated authorization hardware.
And yes, those that use the password "password" or "abc123" deserve to be hacked, because that isn't going to stop someone with a bcrypt database and salt in hand.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
May 18, 2012, 06:14:48 PM
 #996

Thus, with a strong salt making anything but huge rainbow tables ineffective, while some users might have relatively weak passwords that could be solved in reasonable amounts of time, the attackers wouldn't know which they are and would have to attack the entire DB looking for them. How long would it take with a reasonable GPU farm (say 4 5970s) a 6 character case sensitive Latin alphabet password?

It depends on the work-level but lets assume a work level of 10. That means a single core of server can verify a password in ~ 3 ms or 300 p/s.  A 5970 would be ~30x as fast (optimistic) so your might be getting ~ 9kp/s or 36kp/s for 4x5970 rig.

If your password can't be found in a dictionary or easy password list to brute force all 6 char passwords would require
alphabet only (53 values) 53^6 /36000 / 60 /60 /24 = 7 days
alphanumeric (63 values)  63^6 36000 / 60 /60 /24 = 20 days
printable symbols on keyboard (95 values) 95^6 /36000 / 60 /60 /24 = 236 days

If the salt is random per account that means each account must be cracked separately.

Of course the attacker could use multiple GPUs so a good way to think of it is in time value.    A single 5970 can generate ~0.5 BTC per day.  So cracking a 10 BTC account is worth ~ 20 GPU days.  Cracking a 1000 BTC account is worth ~2000 GPU days.  If it takes the attacker longer (in GPU days regardless of actual time) then it isn't worth it to try.

While 6 charecters (not on known password list, not repeated on another site, not a dictionary or common word w/ only 1 or 2 substitutions) is likely good enough.  Still adding just 1 or 2 more character significantly increases the time value cost.  A 7 char (all printable keys) password is ~ 90,000 GPU days (5970s).  The time value is worth 45,000 BTC meaning even if someone had sufficient GPU power it wouldn't make sense to attempt the attack unless the account was worth more than 45,000 BTC.  They could make more mining legit than trying to break the account.  Given the attacker has no idea if he will ever crack it (maybe your password is a purely random 14 character string "pOQs9jb!su3gp@") it doesn't really make sense to even try.

6 is likely "good enough" if your password is complex enough but 7 or 8 chars makes it so expensive the thief isn't going to even try.  In the time it takes to brute force a single 8 char password one can brute force 86,000 other accounts trying all passwords length 1 to 5.
Transisto
Donator
Legendary
*
Offline Offline

Activity: 1624



View Profile WWW
May 18, 2012, 06:28:37 PM
 #997

How is Google authenticator , OTP factored into this cracking time.

Or was something lost about it ?
MrTeal
Legendary
*
Offline Offline

Activity: 1246


View Profile
May 18, 2012, 06:39:27 PM
 #998

Thus, with a strong salt making anything but huge rainbow tables ineffective, while some users might have relatively weak passwords that could be solved in reasonable amounts of time, the attackers wouldn't know which they are and would have to attack the entire DB looking for them. How long would it take with a reasonable GPU farm (say 4 5970s) a 6 character case sensitive Latin alphabet password?

It depends on the work-level but lets assume a work level of 10. That means a single core of server can verify a password in ~ 3 ms or 300 p/s.  A 5970 would be ~30x as fast (optimistic) so your might be getting ~ 9kp/s or 36kp/s for 4x5970 rig.

If your password can't be found in a dictionary or easy password list to brute force all 6 char passwords would require
alphabet only (53 values) 53^6 /36000 / 60 /60 /24 = 7 days
alphanumeric (63 values)  63^6 36000 / 60 /60 /24 = 20 days
printable symbols on keyboard (95 values) 95^6 /36000 / 60 /60 /24 = 236 days


Thanks, very informative.

Sorry to derail the thread with this (not that it's anywhere near the tracks anyway), but I'm genuinely interested. For the above numbers, that would be for a single salted password assuming a dictionary attack fails. The average expected time to crack such a password would be 3.5days, but probably less if they prioritized on common alphabet letters (ie, lowercase e vs uppercase Q). Would the expected attack vector in that case be to use the known work size and then go through each user and their unique salt first using dictionary word, then working out from the minimum password size exhausting successively 4 character passwords, then 5, 6, etc?

If my napkin calculations are right, given the above numbers and assuming 10k users, they would discover all the dictionary passwords fairly quickly (a couple days for a 1 million entry dictionary?), then 10k users * (53^4/(36000*60*60*24*2)) = 12.7 days to discover all the 4 character alpha passwords, a little less than 2 years to crack all the 5 letter passwords, etc. Again, average time might be less than half the full space if they focus on common letters first, but as a ballpark would those numbers make sense?
S3052
Legendary
*
Offline Offline

Activity: 1946


BTC Up or Down? go to www.bullbearanalytics.com


View Profile WWW
May 18, 2012, 06:40:59 PM
 #999

Back to the question of WHEN WILL WE SEE THE FIRST FUNDS BACK TO THE CUSTOMERS? This timing may well lead to more volatility of bitcoin trading and to know this date would be very much appreciated.

>15years analysis experience

Always do your own due diligence & consult your financial advisor. Never invest unless you can afford to lose your entire investment.

http://twitter.com/BitcoinAnalyst

Subscribe here
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
May 18, 2012, 06:54:21 PM
 #1000

Would the expected attack vector in that case be to use the known work size and then go through each user and their unique salt first using dictionary word, then working out from the minimum password size exhausting successively 4 character passwords, then 5, 6, etc?

Yeah that would be the common attack vector.

Generally speaking there are three ways to guess a password.
a) precompiled lists of likely passwords (often 5-8 million based on prior large scale breaches - people love re-using passwords even after breaches)
b) base word dictionary (also contains slang, names, famous people, brands, etc) combined with exhausted or heuristic substitution
c) pure brute force.

The order in which a cracker will use the masks is kinda an art-form.  Some choices are obvious, some choices are more subjective.

There are only 857K total 1 to 3 char passwords so they are often checked first.
Next try your "common password list".
A 4 char brute force usually makes the most sense (81 million).
Around 5 or 6 char brute force starts to not make much sense.  That assumes you are going against something solid like bcrypt.
So usually after 4 or 5 char brute force trying base word + substitution/prefix/suffix makes more sense.

If a site puts restriction on min or max length or invalid char that narrows down the search range.   
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 [50] 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!