Basically, Wordpress is written in PHP and this is the root of all evil.
Let's look at the roots of PHP: it was never designed as a programming language, it was a tiny script language used to create Rasmus Lerdorf's website. Thus, it has a lot of oddities like the === operaor.
Do you know why it it is there? Because they wrote a broken instr() wrapper and messed up the error handling. And instead of doing one thing right, they added another obfuscation layer. Great design.
Then, PHP was traditionally used by webdesigners, not programmers. This lead to tons of bad code and bad practices. It is not that you cannot write elegant code in PHP, but there is so much more bad code around that it is hard to find the good code.
Real hackers can appreciate every damn language out there. If it weren't for Basic in the early 80s, I wouldn't be programming now.
PHP is a wonderful gateway language for a generation of web programmers. It is installed on every webserver and is always ready to rock-n-roll. No other language has achieved that level of ubiquity.
No. We can have a productive discussion about whether a language and its frameworks are conducive to secure coding without it devolving into a language war. We're adults here, and there are more than just stylistic differences between PHP and its competitors.
Don't get me wrong, I like using Python. But I prefer small compromises addressing prior mistakes, allowing for backwards compatibility, over a full rewrite.
I think we're a few years past the arguments you make against PHP. If you want to be trendy, you should rail against the people running Internals (namespace separator).
I've created wordlists from Wikipedia database dumps some time ago (http://benjamin-schweizer.de/files/wordlist-wikipedia/); they are pretty large and thus, useful for dictionary attacks. The wordlists are sorted, common words are on top of the lists.
I think that there is a typical password length, so you could improve the sorting based upon a multi-dimensional rating scheme. I'd use expected password length and commonness of a word as factors. Mixing these real words with computer generated words might speed up brute force attacks.
However, I'm not sure how to integrate ordered wordfiles with rainbow tables. Any ideas?
I don't think word frequency is a good estimator for the likeliness of passwords. Many frequently used words -- like connectors or adverbs -- are unlikely to be used as passwords. I expect proper names (of people, places, or cultural works) are the most common passwords, which are at a relative disadvantage in word frequency lists.
rainbow tables are an implementation of the time-space tradeoff concept: you are trying to search through a space so large you cannot enumerate it. if you have already enumerated it, as in a wordlist, it is not meaningful to use rainbow tables. it's not a question of how; it's not even a well-defined operation.
that's great that you've made that list though.. i wanted word frequency tables for my startup which is an entirely unrelated type of project. if i hadn't found this i would have compiled it myself; thanks much :)
while your list doesn't have frequencies, i guess i can use the position in the list as a proxy for frequencies. but it's not optimal. any chance you can put up a list which also has the counts?
Because other people used it, composed good code and even others adopted it. This resulted in a high-profile Python scene and good code. I think that many new ideas were contributed and it was fun to share ideas. This resulted in a rapid development of toolkits, frameworks and software. If you wanted to be part of this, you had to use Python.
But I think it is the same with JavaScript, Ruby, FreeBSD, PosgreSQL and many more hip foobars; In contrast, Java, PHP, many (not all) Microsoft products, Linux (partly) allured so many bad coders that it is simply boring to work through their code.
WTF? Looks like GMail is feature complete and they dunno what to do... I bet the next thing we'll see is random signatures. Looks like the are implementing a bunch of useless features that all got mentioned in Usenet 15 years ago.
Sometimes, you have to resign to win. If you want to keep these people off of education, how can they improve their own situation? Does this benefit you?
What are the constraints? If it's processing time or memory, I'd choose the XOR solution (which is brilliant). But it could also be the time to solve the problem. This would mean that the first working solution that comes to mind would be the best. Or the solution should be transparent to non-programmers, which probably eliminates the XOR hack. It could also be the joy while coding...
Let's look at the roots of PHP: it was never designed as a programming language, it was a tiny script language used to create Rasmus Lerdorf's website. Thus, it has a lot of oddities like the === operaor.
Do you know why it it is there? Because they wrote a broken instr() wrapper and messed up the error handling. And instead of doing one thing right, they added another obfuscation layer. Great design.
Then, PHP was traditionally used by webdesigners, not programmers. This lead to tons of bad code and bad practices. It is not that you cannot write elegant code in PHP, but there is so much more bad code around that it is hard to find the good code.
So, why do wonder about this?