• BRG_HP (homepage)
• BRG3 / BRG4 (board)
• BRGblog (weblog)
• BRGwiki (wiki)
• BMS (blog management system)
• BDB (BRGproj development blog)

>>> zur Dokumentation

Sie zeigt Zeitleisten, Statistiken und beschreibt die Ereignisse rund um meine ersten Softwareprojekte.

Großer Dank an Peter, Stefan und Toja!

> 2) Aren’t we supposed to check for SQL-injection?
No, the course has nothing to do with security.

via tugraz Newsgroup.

<IMHO>I agree, that you should not mix up course contents. But I disagree that good practice should not be taught. So: Disagree.</IMHO>

Please repeat yourself and reinvent the wheel. This is where the software industry is going nowadays. The boundaries between company contexts and voluntary projects are too broad to be crossed in a copyright-driven society.

based on spikedmath:456.

• There is more interaction between students and professors than here. Students here prefer not to question lecture content and questions to the audience have higher response times than in Harvard. I think one of the major reasons include the missing reaction to problems (“XY at slide Z is incorrect” will be ignored even though the lecturer agreed at the lecture).
• The professor is well prepared and has a specific topic to finish in one lecture. Whereas the second is true in most cases here, the first one cannot be satisfied by slides of previous years and out-dated course websites
• Specifically about this topic: The first OOP source code of PHP you will see here is out-dated PHP 4. Even though there are more lectures, topics like scalability are not part of the course here.

Liked it

Marzipan Animals

Marzipan animals

The internet is filled up the bug reports… some are having specific plugin problems, some only get blank PDF pages. Well… this Inkscape 0.47 bug report got the solution for me. Remove the preferences.xml file (for me ~/.config/inkscape/preferences.xml) and Inkscape will create a new one when starting up.

What is the reason? I think some important package got upgraded and Inkscape is holding some old, conflicting information about this package.

Tags: Inkscape 0.47 pdf export SVG could not be saved preferences cairo

“switch in amd64 assembly” [HTML]

Login Managers

During installation you will face a select field like this (in the “Security Setup” section):

All those selections refer to different password management backends. Twiki::Client::ApacheLogin is implemented by /twiki/lib/TWiki/Users/ApacheHtPasswdUser.pm and Twiki::Client::TemplateLogin is implemented by /twiki/lib/TWiki/Users/HtpasswdUser.pm. In /twiki/lib/TWiki/Users/Password.pm the interface is defined. You can check out funny source code sequences like this:

Well… this is our interface. Let’s have deeper look into the implementation.

Twiki::Client::ApacheLogin

ApacheLogin uses the Apache interface to send 401 HTTP Status codes. If the client receives one of those status codes, a Username and Password Dialog pops up.

Using this dialog, the login information will be sent to the server. Using a loop in perl, we can print out what the server receives as CGI variables (the ones defined by the server and given to the perl interpreter). I have put the following source code into /twiki/lib/Twiki/Users/HtPasswdUser.pm subroutine new (don’t forget to include Data::Dumper).

From the Apache log, we will get the following information.

[...]
HTTP_COOKIE = 'TWIKISID=d00fe404e65832f9d95658d6d9112bec';, referer: /twiki/bin/logon/TWiki/TWikiRegistration
[...]
REDIRECT_REMOTE_USER = 'LukasProkop';, referer: /twiki/bin/logon/TWiki/TWikiRegistration
[...]
REDIRECT_STATUS = '401';, referer: /twiki/bin/logon/TWiki/TWikiRegistration
[...]

Actually I was looking for REMOTE_USER, which is a CGI variable only defined when Authorization was done. The cookie is not really interesting, but REDIRECT_STATUS approves that auth was done. REDIRECT_REMOTE_USER seems to be REMOTE_USER I am looking for… in some way. Alright… so what do we have here? Well… password and username associations are tested automatically by the Apache server and perl will not receive the password itself. Perl can assume that auth was done successfully and does not recognize it any further. Alright. So we have to determine where the passwords are stored.

Passwords for mod_auth are stored in .htpasswd files. A small UNIX find will return /twiki/data/.htpasswd. This file is updated for each change by the perl script.

LukasProkop:11/Yysc0Op9D2:unixuser@localhost

So the password is stored as a hash associated with the Login name and the local user name. Now let’s come to our real topic: Passwords with more than 8 characters. Let us create some additional accounts.

Well… our .htpasswd says:

CarminaBurana:UXjIprwRygc1.:unixuser@localhost
DiesIrae:UtCp6NoUsQdaQ:unixuser@localhost
KarlOrff:7kQC9KJ/39yA.:unixuser@localhost
LukasProkop:11/Yysc0Op9D2:unixuser@localhost
SixteAjoutee:R07ipKyeiYlho:unixuser@localhost

Now let’s log in with various accounts. As far as Twiki does not support a Logout button, the most comfortable way is to delete the cookie (see above) and refresh the page. Now we can see our problem: SixteAjoutee and DiesIrae can log in with each other ones password. The strange thing is, that their hashes are different. Our source code journey goes on…

Violation of second-preimage resistance?

$TWiki::cfg{Htpasswd}{Encoding} = 'crypt';

Our configuration file at /twiki/lib/LocalSite.cfg defines a variable for the various encoding algorithms. Of course such a variable is a perfect name to search for. The configure uses this variable, but HtPasswdUser.pm is the only other file.

The file encrypting the password is HtPasswdUser.pm at line 134. This file will apply the crypt function with a random salt to the password. The salt is 2 characters in length and stored at the front of the actually stored password. A small test script reveals the truth:

So there we have our problem. crypt uses the DES algorithm from the operating system and is limited to an input of 8 characters.

The collision-free solution

Of course the algorithm is the problem and a selection of another algorithm like sha1 (nope, no MD5!) would solve the problem. We do not rely on the operating system or missing implementations of other crypto algorithms.

This program returns two different hashes:

{SHA}sgDumzcRNpPJL8tCgM18JIR1ayc=
{SHA}RsUxZFkQgYAeTdsPmIixTYEdFgg=

Migration

How can thousands of user accounts be migrated to another algorithm? As far as the hash is stored as a one-way encrypted string, the encryption of the real password with another algorithm is almost impossible. I have written a small crypt() cracking program in python (sorry, Perl ), but of course it is way too slow; even for a single password. So the only solution is to reset all passwords of all users. First call the /twiki/bin/configure script and change the algorithm setting (“{Htpasswd}{Encoding}” in the “Security Setup” section) [0] and secondly, BulkResetPassword will help you reset the passwords for all users. It takes some effort and time, but in the end you will gain a higher level of security

[0] It is also possible to directly modify the $TWiki::cfg{Htpasswd}{Encoding} line in /twiki/lib/LocalSite.cfg

diff --git a/wp-content/plugins/wordpress-importer/wordpress-importer.php b/wp-content/plugins/wordpress-importer/wordpress-importer.php
index 5e38484..e0cace0 100644
--- a/wp-content/plugins/wordpress-importer/wordpress-importer.php
+++ b/wp-content/plugins/wordpress-importer/wordpress-importer.php
@@ -102,6 +102,7 @@ class WP_Import extends WP_Importer {
         * @param string $file Path to the WXR file for importing
         */
        function import( $file ) {
+               $file = ABSPATH . 'wp-content/uploads/wordpress.import.xml'; #wp_import_handle_upload();
                add_filter( 'import_post_meta_key', array( $this, 'is_valid_meta_key' ) );
                add_filter( 'http_request_timeout', array( &$this, 'bump_request_timeout' ) );

@@ -132,7 +133,7 @@ class WP_Import extends WP_Importer {
        function import_start( $file ) {
                if ( ! is_file($file) ) {
                        echo '<p><strong>' . __( 'Sorry, there has been an error.', 'wordpress-importer' ) . '</strong><br />';
-                       echo __( 'The file does not exist, please try again.', 'wordpress-importer' ) . '</p>';
+                       echo __( 'The file '.htmlspecialchars($file).' does not exist, please try again.', 'wordpress-importer' ) . '</p>';
                        $this->footer();
                        die();
                }
@@ -188,7 +189,7 @@ class WP_Import extends WP_Importer {
         * @return bool False if error uploading or invalid file, true otherwise
         */
        function handle_upload() {
-               $file = wp_import_handle_upload();
+               $file = array('id' => 4869, 'file' => ABSPATH . 'wp-content/uploads/wordpress.import.xml'); #wp_import_handle_upload();

                if ( isset( $file['error'] ) ) {
                        echo '<p><strong>' . __( 'Sorry, there has been an error.', 'wordpress-importer' ) . '</strong><br />';

I did not put any further (compatibility) research into that issue. Worked for me™ with WordPress Version 3.2 and PHP Version 5.3.

WordPress FAQ: Import and Export