Xeoncross

I know this topic is now old enough to be legend, but @jrw4 did you ever got anywhere with switching to XMLReader? It seems like libxml's DOM and SimpleXML should be able to handle this. $dom = new DOMDocument('1.0', 'utf-8'); $element = $dom->importNode(dom_import_simplexml($xml->node->here), true); $dom->appendChild($element); return $dom->saveHTML();

Problem solved. I am on a windows box and so since the text I was reading from was in a text file it had the windows "\r\n" instead of "\n". It's the simple things that get you. $text = str_replace("\r\n", "\n", $text); So all those codes do work.

Thanks, that is along the same idea. But I don't want each new line starting with a ">" to be a new blockquote. If you look back at the old emails there were often many lines in replies / forwards that started with a ">". So I want all of those (up to two line brakes) to be counted as a single blockquote. With your code I would have a new blockquote for each line which won't work. Thanks Joe >Joe wrote: >Sent you your check >-Joe To allow laziness, I also want to just look for something that starts with a ">" and goes to two line brakes (\n\n) even if those other lines don't start with a ">". Thanks Joe >Joe wrote: Sent you your check -Joe -Sam (outside of the blockquote)

Do you think that we could also increase the code size? 9pt is a little small on a 1280 or lager screen. Plus the outside border is a bit close to the text so a increased padding would be nice. font-size: 10pt; width: 98%; padding: 1%; border: 1px solid #aaa;

The PHP markdown reports a regex almost like this which also works in regexpal. (^>.+\n(.+\n)*)+ However, like the other regex's above it either selects nothing, or with the "m" modifier selects almost everything.

Markdown is one of the few markup tools that selects ">blah, blah..." styled old-fashioned email quotes and converts it into HTML blockquotes. I have been trying to do that with PHP but I just can't get it together. So far I have lots of regex patterns that work in regexpal - but not PHP. And I can't figure out why. I have used the /.../m and other modifiers yet it won't cache the string right. (^>([^\n]+(\n|$)+?)+?) ^>(([^\n]+\n)+?) ^\>((.|\n)+?)\n\n <this is some text >followed by an invalid quote >this is a real quote > this is a quote that is broken up across lines >Another quote >with a starting >> sign Just plain text >End quote The goal would be to catch all lines that start with a ">" followed by EVERYTHING upto two returns "\n\n". That should be a standard quote.

lol, if you can call that an ad (ads should sell something). You missed all the good discussion, but we are still looking for new and better algorithms and ideas for (portable) hashing.

and yes, it wasn't until the third yellow comment that I looked over to realize that it was two different people.

Yes, you get so used to people asking dumb questions around here right? I know the same feeling... Actually, I just tested this attack example out on a much larger site and I found some users that seem to have more cash than a low-pay programmer like me - would you like their info better? This text is for all you newbies out there - one security measure isn't enough. This topic was solely about portable hashing algorithms (then salting). That should make up about 5% of your general site security check list. If you want a better start watch my video.

and I was hoping to eat today.... :-\ You are right that if they can access the DB then the attacker can mess you and your site and/or users up big time. However, the thing we are trying to protect in this instance is the user data. That attacker wants desperately to get the users password because they know that at least one of the users of your site must use the same password for their bank account. With no salt there a good chance they can crack at least 40% or so of the users with simple [a-z0-9+=\$#etc..]{4,10} passwords. With a dynamic salt for each user (a nonce) then they now can no longer use the Rainbow tables for the user checks. They have to recreate the ENTIRE rainbow table database for EACH USER (user_salt + pass). What a pain. Even worse, if that salt is over 12 char/symbols long (which most passwords by themselves aren't) then they probably can't even create a DB large enough to find a match (32 char salt + 6 char pass = 38char string). Rainbow tables are 128GB by the time you reach 12chars. Salting is a way of life.

Good, I'm hungry. [*]Without salting, your user enters the password "1sK2qk4o0". [*]Someone breaks into your DB server and seals user rows (with password hashes). [*]a local copy of something like http://project-rainbowcrack.com/ is already setup on the attackers PC with up to 9 char ([a-z][0-0]#) hashes made (56GB). [*]Checks user_a pass hash against his DB, a couple seconds later he's found it. VS salts Oh, and when I say portable I mean that you can move the password hashes around servers and the resulting hash of a string will be the same on all servers. crypt() yields different results on different servers which is a problem when using more than one server or changing servers.

Thanks for the reply 448191, that was the input I was looking for. I can always count on you to post coarse, yet very useful information. As I stated before, I am not really worried about people stealing my users data - there is nothing personal there but an email. However, staying ahead of the curve is important so that you don't wake up one day behind. By the way, you wouldn't happen to know if sha256 is portable would you?

That's is another good idea. There are lots of things that can be done to secure sites & servers. However, this thread is specifically about better hashing algorithms for creating portable hashes. I personally would be using bcrypt if it wasn't for this problem.

lol, your database is outside your root directory too...

Yes, especially for sites that contain non-financial data. However, this is a chance for a learning opportunity. If I can change the time it would take a PC to crack a password from 8 months to 5 years - it is worth the time it would take to learn. Now take passwords that do not have a salt. Again, assuming that this is a chance that the server is compromised - if they can access the DB - they can probably also get my config file or DB salt for use in their brute-forcing. Thereby removing the benefit of the salt.