Beiträge von osiris

Zitat von Alex_K

Optional noch eine /home Partition (die kann einem viel an Daten hin und her kopieren ersparen wenn man eine neue Linux Version installieren will - ich hab dazu sogar eine eigene Festplatte).

Würde es da Sinn machen, wenn man die swap-Partiton angelegt hat, den restlichen Speicherplatz einfach 30/70 auf / und /home zu verteilen?
Das wären bei mir etwa 80 GB /home und ca. 35 GB "/".

Andererseits: Eine neue Linux-Version zu installieren heißt entweder einen neuen Kernel einzubauen oder (unter Debian) apt-get dist-upgrade (wenn man vorher die source.list geändert hat). Für keines von beiden muss ich meine persönlichen Daten irgendwo hinkopieren (außer als Backup).

Da würde sich evtl. auch eine extra Homepartition erübrigen.

Ja, stimmt. Reguläre Ausdrücke braucht man hier nicht.
Die for-Schleife ist nicht schlecht.
Aber die löst ein Problem meines komischen Generators nicht ganz (auf das ich hier nicht näher eingehen möchte, weil dann womöglich einigen hier die Haare zu Berge stehen ).

Ich habe jetzt nochmal intensiv php.net usw. gequält und da ein wundersames Werkzeug namens str_shuffle gefunden.
Damit klappt's!

Zitat von spinball

Wir sollten Geld dafür verlangen.

Keine Angst, ich bekomm auch keins.
Das ist hier so eine Art Hobby mit Auftrag.

Das Problem ist, dass lediglich die Funktion preg_replace die Möglchkeit bietet ein Maximum für die Ersetzungen in einem String festzulegen.

Ich möchte nämlich immer nur genau ein Zeichen löschen. Das heißt, wenn der Zeichensatz z.B. 4%4mXW5z wäre, sollen nicht auf einmal die beiden "4" gelöscht werden, sondern nur eine von beiden.

Wenn das nicht nötig wäre, könnte ich das ganze natürlich auch ohne regex realisieren.

Das Problem liegt also offensichtlich in $pw_charset, weil das die Zeichen -@%/[]()+*?!$ enthalten kann.

Konnte man die nicht mit einem Backslash "ausklammern"? Das Problem wäre dabei aber wieder, dass das Backslash überall dort, wo ich sonst mit $pw_charset arbeite als einfaches Zeichen interpretiert wird.

Guten Morgen,

ich schreibe grade an einem zugegebener Maßen etwas eigenwilligen Passwortgenerator, dessen Kern folgende while-Schleife ist

$pw = NULL;
$del = NULL;


while (strlen($pw) < 8) {


	$pwchar = $pw_charset[rand(0, strlen($pw_charset)-1)];
	echo "Zeichen. ".$pwchar;
	echo "<br>";
	$pw = "$pw$pwchar";
	echo "Passwort bisher: ".$pw;
	echo "<br>";
	$pw_charset = preg_replace("/$pwchar/", $del, $pw_charset, 1);
	echo "Neuer Passwortzeichensatz: ".$pw_charset;
	echo "<br>";
	echo "L&auml;nge des Zeichensatzes: ".strlen($pw_charset);
	echo "<br>";
}

Die Ausgabeanweisungen sind jetzt nur drin, damit ich sehen kann was jeweils passiert.

Das Problem, dass ich mit diesem Skript habe ist, dass es manchmal eine Endlosschleife produziert. Manchmal aber auch nicht. Ich hab mir schon den Kopf darüber zerbrochen, woran's liegen kann. Finde das Übel aber nicht. Obwohl: Das sitzt ja bekanntlich vorm Monitor. :distur:

Jedenfalls sieht die Ausgabe bei der Endlosschleife so aus

Zufälliger Großbuchstabe: S
Zufälliger Kleinbuchstabe: n
Zufällige Zahl: 9
Zufälliges Sonderzeichen: *
Zufallskette aus 4 weiteren Zeichen: cv([


Passwortzeichensatz: Sn9*cv([


Zeichen. n
Passwort bisher: n
Neuer Passwortzeichensatz: S9*cv([
Länge des Zeichensatzes: 7
Zeichen. 9
Passwort bisher: n9
Neuer Passwortzeichensatz: S*cv([
Länge des Zeichensatzes: 6
Zeichen. c
Passwort bisher: n9c
Neuer Passwortzeichensatz: S*v([
Länge des Zeichensatzes: 5
Zeichen. S
Passwort bisher: n9cS
Neuer Passwortzeichensatz: *v([
Länge des Zeichensatzes: 4
Zeichen. [
Passwort bisher: n9cS[


Warning: preg_replace() [function.preg-replace]: Compilation failed: missing terminating ] for character class at offset 1 in /usr/local/apache_1.3.33/htdocs/siemi/tests/gen_pw.php on line 50
Neuer Passwortzeichensatz:
Länge des Zeichensatzes: 0
Zeichen.
Passwort bisher: n9cS[
Neuer Passwortzeichensatz:
Länge des Zeichensatzes: 0
Zeichen.
Passwort bisher: n9cS[
Neuer Passwortzeichensatz:
Länge des Zeichensatzes: 0
...

Das hat ganz offensichtlich was mit preg_replace, also meinem Lieblingsthema (Reguläre Ausdrücke) zu tun.
Vielleicht sollte ich mal etwas über die Grundlagen der Programmierung lesen... :idea:

Ok,
sieht so aus, als ob das wirklich alles unnötiger Stress wäre.

Am einfachsten und effizientesten ist wohl, wenn ich 100 MB /boot, 2 GB swap und den Rest für "/" anlege.

Das ist, denke ich, relativ einfach zu bewerkstelligen.

Die Reihenfolge würde ich so wählen: /boot, swap, "/".
Mal sehen, wie ich das jetzt verschlüsselt bekomme.

Danke für dei Ratschläge!

Zitat von Stefan Kögl

Wo steht das?

Debian Installations-Anleitung, C.2. Der Verzeichnisbaum

Zitat

Vielleicht ist das aber auch eine ungute Entscheidung in Bezug auf den Echtzeitkernel?

Eventuell könnte das bestimmte zugriffe von Echtzeitanwendungen verlangsamen, wenn man mit verschiedenen Partitionen arbeitet?

Zitat von bimbo

und den Rest an "/"

Wieviel braucht den "/", wenn man das mal reichlich bemisst?

Hallo nochmal,

ich hab mir das jetzt nochmals alles durchdacht und es haben sich noch paar Punkte ergeben, die ich nicht richtig klären kann.

Zuerst einmal hatte ich im obigen Beispiel natürlich die "/"-Partition vergessen!

Und mit der habe ich auch ein Problem:
Im Debian-Handbuch steht, dass diese normalerweise mit 150-250 MB auskommt.
Das begreife ich nicht: "/" enthält doch alles, was nicht auf einer extra Partition angelagert ist. Da würde also z.B. /usr mit reinfallen. Was, wenn ich in /usr/share die Offlineversion der Wikipedia ablegen will (die ist einige GB groß)? Da reichen 250 MB ja auf keinen Fall. Und selbst, wenn man nicht so wahnsinnig große Datenmengen dort ablegt, scheint das viel zu knapp bemessen zu sein. Oder habe ich da was falsch verstanden?

Außerdem wollte ich mal wissen, ob man die /boot-Partition nicht lieber mit 100 MB anstatt mit den empfohlenen 50 MB anlegen sollte, weil die ja die bootbaren Kernelimages enthält.
Ich werde auf meinem System z.B. 2 verschiedene Kernel laufen haben: Einen Echtzeit-Kernel und einen der nur das Nötigste zum Arbeiten bietet. Dazu gibt's natürlich als Sicherheit erstmal noch den Standard-Kernel.
Könnte ja sein, dass ich damit über 50 MB hinauskomme oder?

Dann wollte ich jetzt nochmal näheres zu Sinn und Unsinn einer seperaten Homepartition wissen, wenn ich nach dem obigen Schema partitioniere.
Ich meine, ich müsste die wohl schon anlegen, wenn ich will, dass die Platte vollständig partitioniert ist und es keinen leeren Raum gibt.
Vielleicht ist das aber auch eine ungute Entscheidung in Bezug auf den Echtzeitkernel?

Nun noch zu den Nachteilen einer Partitionierung:
Momentan habe ich ein System laufen, auf dem es seperate Partitionen für /home, /usr, /var uns /tmp gibt (Hat der Debian-installer für mich erledigt). Die sind alle verschlüsselt.
Performanceeinbußen habe ich dabei noch keine mitbekommen und selbst bei einem Systemcrash wegen eines entladenen Akkus hat hinterher alles einwandfrei funktioniert. Insofern habe ich da keine Bedenken.

Hallo,

ich will die Lebensdauer von Passwörtern in meiner DB begrenzen. Ich habe mir dazu schon mal ein paar Gedanken gemacht und mal etwas das Web durchforstet.

Dort findet man halt viel dazu, wie man Passwörter erstellt, aber nichts zu Begrenzung der Lebensdauer.

Ich hab auch auf php.net mal gezielt nach Funktionen gesucht, die Begriffe wie time, expire, password usw. enthalten. Da kam aber nichts sinnvolles raus.

Meine Idee:

Der Countdown für die Lebensdauer (x) des Passwortes startet mit dem ersten Login des Users. Deshlab müsste man diesen Zeitpunkt in der Datenbank ablegen.
Dann müsste es ein Skript geben, dass in bestimmten Zeitabständen prüft, welche Passwörter ungültig sind und diese aus der DB löscht.
Dabei stellen sich mir 2 Probleme:
Wie schreibe ich ein Skript, das automatisch startet?
Und wie müsste man den Zeitabstand wählen, damit jedes Passwort auch genau nach x Tagen ungültig wird und nicht 5 Minuten fürher oder 3 Stunden später?

Vielleicht könnt ihr mir ja mal paar Tipps geben.
Links würden genügen.
Danke!

Okay, nach allem, was ihr so geschrieben habt, werde ich wohl folgende Varinate ausprobieren:

1. Extra Partintionen für /boot, swap und /home
2. Alles bis auf /boot verschlüsseln
3. Für den Gast-Account und das PHP-Verzeichnis (Danke für den Hinweis!) Quotas benutzen.

Da werde ich meine Platte wohl manuell Partitionieren müssen. Das wird wohl ein kleines Abenteuer werden. Aber ich mach ja eh erstmal eine Testinstallation auf meinem alten Desktop-PC.

Zitat von Stefan Kögl

Kapier ich nicht... Warum sollte der MD5-Hash unterschiedlich sein müssen, damit das funktioniert?

Hab ich mich ungut ausgedrückt: Es ging eher darum, dass trotz, dass die beiden Nutzer ein identisches Passwort haben, in der DB zwei unterschiedliche MD5-Hashes stehen.

Zitat

Was weiß der Angreifer in deinem Szenario?

Im schlimmsten Fall wohl das, was in diesem Forum steht.

Zitat

Du solltest vielleicht mal ausrechnen, wie wahrscheinlich es ist, dass das passiert...

Hab ich mir auch schon gedacht. Es gibt immerhin etwa 24000 mögliche Nutzernamen.

Welche Maßnahmen würdest du denn hier ergreifen anstatt das so umstänlich zu machen?

Zitat

Auf einem Notebook das Homeverzeichnis verschlüsseln ist nur die halbe Miete: Auch aus Log- und Konfigurationsdateien ziehen Diebe und unehrliche Finder Rückschlüsse.

Quelle: Linux Magazin

Der Nutzer hat in diesem Fall nicht die Möglichkeit sein Passwort zu ändern.

Da aber der Versand des Passwortes per Mail nicht sicher ist, wird nach der ersten Anmeldung für jeden Nutzer noch ein Code erzeugt - sozusagen als zweite Sicherheitsstufe.

Warum das jetzt so und nicht anders gemacht werden soll, weiß ich nicht. Hab mir das nicht ausgedacht.

Die Tatsache, dass kein Passwort doppelt verwendet werden darf, macht es einem eventuellen Angreifer schwerer zu einem brauchbaren Ergebnis zu kommen.
Andererseits: Wenn jetzt tasächlich mal ein identisches Passwort erzeugt werden sollte und sich zwei User mit dem selben Passwort anmelden, wäre das ja auch möglich, weil der MD5-Hash trotzdem unterschiedlich ist.
Ein Angreifer wüsste also nicht, dass diese User das selbe Passwort haben.

Aber was ist dann, wenn der eine Nutzer zufällig mal den Usernames des andern eingibt, weil die sich z.B. nur an einer Stelle unterscheiden? Da ist dann schon wieder das Problem.

Also bei mir funktioniert das momentan so:

Ein Nutzer, der sich registrieren will, gibt lediglich sein Mailadresse ein. Nutzername und Passwort werden automatisch erstellt und per Mail versandt.
Wenn also ein Passwort schonmal verwendet wurde, bekommt der Nutzer das gar nicht mit.

Nun ja, das sehe ich schon in gewisser Weise ein.
Aber: Ich werde auf dem PC einen Gastaccount anlegen, damit er auch problemlos von anderen Leuten benutzt werden kann.
Und damit die mir nichts kaputtspielen können, sehe ich schon Sinn in der Partitionierung.

Aber da könnte ich jetzt natürlich auch einfach 2 Homepartitionen anlegen. Oder besser gesagt, die Homepartition teilen.
Damit hätte ich auch gleich den Speicherplatz für den Gastaccount beschränkt.

Zitat von Kampi

moderne distributionen (siehe ubuntu) legen nicht mehr so viele partitionen an.

Stimmt. Debian ist halt ein wenig konservativ. Aber das ist, finde ich, durchaus angebracht. Nicht umsonst läuft diese Distribution so stabil.

Zitat von Kampi

eine kleine /boot auf ext2 kann sinn machen

Welchen Sinn macht das genau?

Zitat von Kampi

eine "/" (root), eine swap. von mir aus noch eine eigene "/home", die du verschluesselst.

Ich denke, man sollte am besten immer alles verschlüsseln, weil ja nicht nur in "/home" sensitive Daten liegen können.

Danke für die Hinweise!

Zitat von beefy

Was soll das fuer einen Sinn machen? Und warum hast du nicht einfach ein Feld fuer den Benutzernamen und ein Feld fuer das Passwort?

Natürlich gibt es in meiner Datenbank jeweils ein Feld für die Usernamen und ein Feld für die Passwörter.
Das Passwort soll aber nicht im Klartext gespeichert werden, sondern als MD5-Hash.
Als ich mir darüber was durchgelesen habe, bin ich auf folgenden Hinweis gestoßen:

Man sollte nicht nur das Passwort alleine verschlüsseln, sondern entweder zusammen mit einen zufälligen String oder einfach dem Username, also

md5($passwort.$username)

Das macht es dann aber eben etwas schwieriger nachzuprüfen, ob ein Passwort bereits existiert. Dazu müsste man wie gesagt:

1.
Das Feld mit den Usernamen holen.

2.
Das neu erstellte Passwort (wenn sich jemand registriert) jeweils mit jedem bestehenden Nutzernamen hashen und die Resultate in einem Array ($hashes2) ablegen.

3.
Anschließend müsste man nachsehen, ob es zwischen $hashes2 und dem Array mit den bestehenden MD5-Hashes ($pwdhs) Übereinstimmungen gibt.
Wenn ja, dann ist es äußerst wahrscheinlich, dass diese Übereinstimmung an den Stellen $hashes2[user_xy] und $pwdhs[user_xy], also beim selben Nutzer vorkommt.
Das heißt wiederum, dass das "neue" Passwort, mit dem user_xy gehasht wurde schon besteht - und zwar eben als das Passwort von user_xy.
Dashalb darf es nicht verwendet werden.

Zitat von spinball

Lieber osiris, ich konnte selbst beim 3784973498. mal Durchlesen nicht verstehen, was du vorhast.

Na ja, trotzdem danke, dass du's dir so oft durchgelesen hast.
Ich hoffe ich hab's jetzt ein wenig verständlicher formuliert.

Hallo,
ich habe hier ein kleines Problem bei der Passwortverwaltung in einer Datenbank:

Das für den Nutzer erstellte Passwort wird in der DB als MD-5-Hash aus Passwort+Nutzer abgelegt.
Es soll aber vermieden werden, dass zwei Nutzer das selbe Passwort haben.

Das würde ich wie folgt prüfen:

Ich hole ein Array mit den vorhandenen Nutzernamen ($users) und eines mit den vorhandenen Passwort-Hashes ($pwdhs) aus der Datebank.

Dann erstelle ich ein weiteres Array, in welchem ich das neu erstellte Passwort mit jedem existierenden Nutzernamen hashe ($hashes2).

Nun müsste ich $pwdhs mit $hashes2 abgleichen und wenn sich an irgendeiner Stelle eine Übereinstimmung erbigt, muss der Zufallsgenerator nochmal ran, weil es das Passwort dann schon gitb.

Die erste Frage, die sich mir hier stellt, ist, wie ich alle Werte aus $users in einer Schleife mit dem neuen Passwort hashen kann.

Dabei geht es erstmal darum, wie man einen Wert in $users adressiert. Da stehen ja jetzt nur die Nutzernamen drin.
Zweitens muss der entsprechende Wert dann noch $hashes2 zugewiesen werden, was ich hinbekommen würde.

Ich bräuchte folglich irgenwas wie etwa

md5($users[x].$pwd) = $hashes2[x]

Das scheint aber so nicht zu funktionieren.

Der Abgleich könnte dann wohl mit foreach gemacht werden. Aber da blicke ich nocht nicht ganz durch.

Kann mir da mal jemand einen Anhaltspunkt geben? Danke!

Nun ja, das Problem ist bloß, dass sich ja dadurch natürlich auch der Hashwert ändert, wenn das Passwort Sonderzeichen enthält, die umgewandelt werden.
Wenn also der Nutzer das Passwort dann im normalen Klartext für einen Login eingibt, wird das nicht funktionieren, außer, wenn man das ganze mit

htmlspecialchars($passwort) abgleicht.

Außerdem löst dein Vorschlag nicht das Problem mit dem  ( Â). Das wundert mich ein wenig, weil ja das "&" eigentlich umgewandelt werden sollte.

Ich frage mich aber gerade, ob sich der Aufwand lohnt, um das ordentlich hinzubekommen. Schließlich gibt man das Passwort ja nicht auf dem Bildschirm aus.
Und es handelt sich hier ja einzig und allein um ein Problem von HTML.
Deshalb müsste das doch eigentlich auch so funktionieren, wenn ich den MD5-Hash des Passwortes speichere und dann mit dem der Formulareingabe des Nutzers abgleiche. Sicherheitshalber habe ich alle Sonderzeichen aus $spex entfernt, die auch eine spezielle HTML-Kodierung haben:

$spex = "-@%/[]()+*?!$";

Soo: Warum ist der Biaswert 127 bzw. 1023? Ganz einfach:

Entgegen meiner bisherigen Annahme, lassen sich in einem 8-Bit-Exponenten nur die Zahlen -126 bis 127 darstellen (bei 1023 sind das -1022 bis 1023).

Das ist so, weil

die (Biased-)Exponenten 0000 0000 und 1111 1111 (bzw. das ganze mit 11 Bit) für spezielle Zwecke gebraucht werden.
Das macht auch deshalb Sinn, weil man -128 + 127 gar nicht vorzeichenlos darstellen kann.

Dann nochmal zu der Sache mit dem hidden bit:

Ich verstehe, dass man das einsparen kann, weil eine normierte Zahl dieses Bit immer impliziert.
Das heißt aber auch, dass die Mantisse z.B. bei single precision eigentlich 24 (und nicht 23) Bit lang ist.
Müsste die Mantisse mit den 23 explizit gespeicherten Bits dann nicht den Betrag der darzustellenden Zahl - 2^n (n = Anzahl der Bits) beinhalten?

Hallo,
ich brächte mal einen Rat bei der Partitionierung meiner Festplatte für mein neues Linux-System:

Ich habe 120 GB Speicher und würde neben der Rootpartition folgendes anlegen:

/swap (2 GB)
/var (3 GB)
/tmp (8 GB)
/usr (10 GB)
/home (80 GB)

Wären also 17 GB für die Root-Partition und alles was darin enthalten ist.

Ich hab mich bei der Aufteilung ein wenig am Debian-Handbuch orientiert.

Ist das eine vernünftige Überlegung?

Ich nutze meinen PC hauptsächlich für Internet, Bürokram, Multimedia (speziell Audioproduktion) und ein wenig zum Programmieren.

Dann noch zwei Fragen:

1.
Ab einer Größe von 6 GB sollte man eine Platte lieber als ext3 statt als ext2 formatieren. Was würde es mir dann im Falle einer kleineren Partition (z.B. /var) für einen Vorteil bringen, diese mit ext2 zu formatieren?

2.
Wenn man seine Platte verschlüsselt (was man speziell bei Notebooks unbedingt tun sollte), überschreibt der Debian-Installer die Platte erstmal sicher.
Mich würde mal interessieren, wie oft jede einzelne Datei dabei überschrieben wird.
Kann ich mir das wie

wipe -r [Festplatte]

vorstellen?

Zitat von Plantschkuh!

Wie du selber schreibst, heißt eine Zahl dann normiert, wenn das erste Bit der Mantisse 1 ist.

Ja, aber das erklärt ja noch nicht, was Normierung einer Zahl genau bedeutet.
Und die Möglichkeit ein Mantissenbit einzusparen ergibt sich dann aus dieser Normierung, aber sie (die Möglichkeit der Einsparung) ist nicht der Grund dafür, dass das erste Bit 1 ist, glaube ich.

Wikipedia sagt bspw.:

Zitat

Die Lichtgeschwindigkeit im Vakuum beträgt c = 299.792.458 m/s = 299.792,458·10^3 m/s = 0,299792458·10^9 m/s = 2,99792458·10^8 m/s. Nur der letzte Wert ist normalisiert.

Heißt Normalisierung also immer, dass die vor dem Komma eine Zahl ungleich 0 stehen muss?
Wäre 29,9792458·10^7 dann auch eine norm(alis)ierte Zahl?

Zitat

Da gibts irgendwelche Übereinkünfte, wie 0 dargestellt werden soll;

Ich habe gelesen, dass die kleinste darstellbare (normierte?) Gleitpunktzahl immer als 0 interpretiert wird.

Zu den Begriffen short real und long real:

Das sind zwei IEEE-Standards, der erste mit 8-Bit-Exponent und 23-Bit-Mantisse und der zweite mit 11-Bit-Exponent und 52-Bit-Mantisse.

Macht (+ Vorzeichenbit) jeweils 32 bzw. 64 Bit insgesamt.

Hierzu hab ich in Wikipedia noch gefunden:

Zitat

In der Norm IEEE 754 werden zwei Grunddatenformate für binäre Gleitkommazahlen mit 32 Bit (single precision) bzw. 64 Bit (double precision) Speicherbedarf und zwei erweiterte Formate definiert.

Dürfte also das selbe sein.

Zitat

Ich denke, der Bias bei 8 Bit sollte 128 sein.

Das glaube ich nicht, denn die Addition des Bias geschieht ja sicherlich im Zweierkomplementsystem (auch wenn das Ergebnis vorzeichenlos gespeichert wird), weil der Exponent auch negativ sein kann.
128 ist aber als Zweierkomplemet mit 8 Bit nicht darstellbar (-128 bis -1; 0 bis 127).
Allerdings wäre selbst der Exponent 127 mit einem Bias von 128 (oder auch andersrum) noch in dieser Weise darstellbar (255). Komisch. Ich glaube, das hat etwas mit der Darstellung der 0 zu tun. Fällt dadurch nicht eine Zahl weg?