Wenn man neue Speicherbereiche nicht vollständig mit eigenen Nutzdaten füllt und diese Blöcke überträgt, kann sich fremder Inhalt mit schützenswerten daten dort einschleichen. Also immer alle Puffer und Strukturen explizit füllen mit Blanks oder 0. Ein einfaches setzen von leeren Strings in Puffern langt nicht, da dies nur eine NULL in das erste byte schreibt und den Rest unberührt läßt.

Wenn mal wieder Backups auf Bändern oder CDs oder wasauchimmer verlorengehen, sollte man vorher an eine Verschlüsselung der Daten gedacht haben. Jedes bessere Backup Programm kann sowas und man sollte das auch nutzen.

Die von Benutzer gewählten Passwörter auf ihre Eignung hin prüfen und dem Anwender die schlechte Wahl zeigen und ggf. nicht akzeptieren.

Am zeitlichen Verhalten kann man ggf. auch Informationen erfahren. Eine schnelle negative Antwort kann so z.B. auf das fehlen eines Users hinweisen, wogegen eine längere Bearbeitung und anschließende negative Antwort wohl eher auf ein falsches Passwort zeigt (vereinfacht darhestellt).
Wer es also besonders sicher mag, der fügt ein zeitliches Rauschen ein, welches alle Varianten der Entscheidungspfade in einen gleichverteilten Zeitnebel taucht.
Das gleiche Problem haben im übrigen Chipkarten, wenn diese am modulierten Stromverbrauch zu viel zu erkennen geben.

Entgegen den meisten Kundenwünschen sollten Passwörter nicht im Klartext in der Datenbank vorliegen, sondern in einem nicht reversiblen hash abgelegt werden.

Eine Passwort Variable sofort nach dem letzen Gebrauch löschen und überschreiben. Die Variable am besten auch non-swappable markieren.

Das ganze betrifft aktuell besonders die Designer von RFID Chips. Diese ziehen unterschiedlich viel Leistung aus ihrem umgebenden Feld, je nach Rechenvorgang. Damit will nun jemand beobachten können, ob der Chip die Verschlüsselung akzeptiert oder nicht und zwar bitweise pro eingehendem Bit. Das kann man anscheinend prima live am Oszilloskop verfolgen. Mal wieder an der falschen Stelle gespart?

Nicht nur nervend, sondern auch in Bezug auf Sicherheit ein Problem:
Eine Anwendung im Hintergrund hält sich selber für wichtig und bringt einen Dialog oder Messagebox in den Vordergrund, also systemmodal. Zusätzlich wird dann auch noch gerne der Dialogfokus auf den Bestätigungsbutten gelegt.
Wenn also nun der Anwender gerade am schnellen Schreiben ist, drückt er in genau diesem Moment entweder die Leertaste oder Enter und hat den Dialog bestätigt, ohne ihn zu lesen oder gar zu sehen.
Schon das Betriebssystem sollte solche Fokuswechsel über Anwendungen hinweg nicht mehr erlauben. Es gibt bei z.B. Windows XP die Sprechblase für solche Meldungen und bei MacOSX kann man das Tasksysmbol hüpfen lassen. Trotzdem sind auf diesen Systemen immer wieder Anwendungen anderer Meinung.
Rettet den Userfokus!

Sind einzelne Einträge aus Datenbanken erst mal weg, ist das Jammern groß. Keiner will es gewesen sein.
Wichtig ist also eine exakte Protokollierung Anwendungsseitig. Wer hat wann wieviel gelöscht? Daraus ergibt sich auch die Forderung nach eindeutigen Nutzerzugängen. Da darf sich nicht mehr jeder unter dem gleichen Account anmelden.

Ein schlechtes Beispiel ist sowas hier:

SELECT tabelle.* FROM tabelle

Man kann nicht vorhersagen, welche Spalten in welcher Reihenfolge zu erwarten sind. Falls jemand nun die Tabelle um ein Feld erweitert, kann die Abfrage sich ganz anders verhalten.
Wenn nun auch noch beim Zugriff nur über Spaltennummern gegangen wird, ist es komplett unverhersagbar. Nur mit benannten Spalten kann das noch gerettet werden:

$rs2=mysql_fetch_row($dbres2);
$tn=$rs2[0];

Denn hier ist es fraglich, welche Spalte die #0 denn nun ist. besser wäre also:

$rs2=mysql_fetch_assoc($dbres2);
$tn=$rs2['id'];