KooKooK (Update 4): Die Authentifizierung im Einzelnen

Vielleicht interessiert es den ein oder anderen, wie ich die Authentifizierung durchführe. Mich würde unbedingt Eure Meinungen interessieren.

Ziel war es, dass man nicht Benutzername und Kennwort über die Leitung zum Server zur Verifizierung überträgt, da ich das für unsicher halte. Ich habe es erst einmal so gelöst:

  1. Client verbindet sich zum Server
  2. TLS-Handshake
  3. Server sendet Welcome-Message an Client. Die Welcome-Message besteht aus der Versionsnummer des Servers sowie einer UUID, getrennt mit einem Doppelpunkt (1.0.1:8234-234-234-234)
  4. Der Client trennt die empfangene Versionsnummer von der UUID anhand des Doppelpunkts
  5. Der Benutzer hat am Client den Benutzernamen und das Kennwort eingegeben
    1. Das Kennwort wird mit MD5 gehasht
    2. Benutzername, UUID und gehashtes Kennwort wird als Bytearray zusammengefasst und mit Keccak_512 gehasht
    3. Daraus entsteht dann das Bytearray, was zum Server geschickt werden soll
  6. Das gehashte Bytearray mit vorangestelltem Benutzername@ wird zum Server geschickt (ausgedachtes Beispiel: thorsten@ljdf08asdflu0dsa98foklj234ASDF)
  7. Der Server hat jetzt den unverschlüsselten Benutzernamen, der eindeutig in der Datenbank ist und zieht das Kennwort, fügt auch alles zusammen und hasht dann das Bytearray
  8. Der Server vergleicht, ob das empfangene Bytearray gleich dem selbst generiertem Bytearray ist. Ja = Der Benutzer ist eingeloggt, Nein = Der Benutzer ist nicht eingeloggt

Anmerkungen: In der Implementierung werden weitere Fehler behandelt und zurückgeliefert. Beispielsweise, ob der Benutzer überhaupt vorhanden ist, ob der Hash gebildet wurde, usw. Was noch fehlt ist, ob der Benutzer auch (in der Datenbank) auf aktiv steht.

Ihr könnt das in folgenden Dateien nachvollziehen:

Mitunter sollte man weitergehen und zum Beispiel auch den Benutzernamen nicht im Klartext senden?

Ich bin wieder in Lohn und Brot – Meine neue Festanstellung und wie es hier weitergeht

Ich bin wieder unter Dach und Fach und freue mich unendlich. Ich habe eine neue Festanstellung gefunden und befinde mich gerade in der Einarbeitung.

Da ich jetzt erstmal, zumindest während der Einarbeitung, in Vollzeit arbeite, habe ich leider keine Zeit mehr für Videos, da ich vollständig mit Job und Familie ausgelastet bin. Damit bleiben die ganzen Serien zuerst einmal stehen.

Wie es da in Zukunft weitergeht, weiß ich noch nicht. Ich danke aber schon einmal bis hierhin und hoffe, den ein oder anderen Blogartikel in den nächsten Wochen schreiben zu können.

KooKooK (Update 3): Umbauten und weitere Informationen

Ich habe mich doch entschieden, einige Umbauten durchzuführen. Zunächst wollte ich den Server eigentlich pro Verbindung mit einem Thread laufen lassen. Das hat direkt, für ein Hobbyprojekt mit wenig Zeit, viele Probleme aufgeworfen.

Von Threads

Vor allem sind die Dateideskriptoren auf unterschiedlichen Betriebssystemen unterschiedlich konfiguriert, aber doch teils sehr limitiert. Ich wollte auf meinem Mac mal eben 500 Verbindungen aufbauen, bei 80 oder so war Schluss. Man kann das Limit zwar höher schrauben, aber man ist natürlich durchaus limitiert.

Dann gab es noch Probleme mit dem Verschieben von Objekten innerhalb von Qt zu Threads. Neue erstellte Objekte liefen nicht im Thread, sondern Hauptthread. Das kann man alles recht problemlos fixen, indem man mit Workerprozessen arbeitet, aber ich wollte da nicht weiter herumbauen (zeitliche Einschränkung), da ich vorwärts kommen wollte. Aber interessant: Ich habe mal 500 Konnektierungen gleichzeitig startet (so gleichzeitig, wie es nur geht). Das hat auf meinem Mac 200ms (etwas darunter) benötigt, um auf 500 Verbindungen ein “Hallo Welt” über das Loopback-Device zu senden. War zwar nur Loopback, aber ich war doch erstaunt, wie schnell es geht, so viele Threads zu öffnen, was zu schicken und wieder zu schließen.

Keine Threads mehr

Dann habe ich einfach mit generellen nonblocking Sockets herumgespielt (im Thread waren sie auch nonblocking!) und festgestellt, dass es von der Geschwindigkeit her für einige hundert Verbindungen ausreichen sollte, zumal man nicht sonderlich viele Informationen senden muss und diese ja auch noch komprimieren kann. Also habe ich alles umgebaut.

Benutzerauthentifizierung

Ich habe das tatsächlich so ähnlich, wie im vorherigen Blogeintrag, implementiert. Letztlich ist es so: Der Client macht eine Authentifizierungsanforderung an den Server. Der Server kennt den Benutzernamen und schickt eine UUID. Dann werden die Benutzerinformationen mit der UUID zusammengefasst und gehasht, zurückgeschickt, der Server macht das selbe und vergleicht beide Ergebnisse. Sind sie gleich, gilt der Benutzer als eingeloggt.

Weiteres

Weiterhin habe ich noch Datenbankabstraktionen implementiert für MySQL, PostgreSQL und SQLite, damit man Benutzer speichern kann. Ein Logging habe ich implementiert und dem Server kann man Signale schicken, um ihn zu beenden oder sonst was zu tun. Es gibt einen Testclient unter resources/sslclient, mit dem man mit dem Server ein wenig spielen kann.

Hier geht es übrigens zum GitHub-Repo.

KooKooK (Update 2): Überlegungen zur Benutzerauthentifizierung

Benutzer sollen sich am System anmelden können. Ich dachte mir, die speichern wir einfach in einer relationalen Datenbank, da Qt dafür schon Bibliotheken mitbringen (MySQL, PostgreSQL, SQLite). Welches DBMS wir nehmen, weiß ich noch nicht.

Dennoch muss die Benutzerauthentifizierung ja implementiert werden. Naiv könnte man das so machen:

  1. Client schickt Benutzernamen und Kennwort an Server
  2. Server prüft per Datenbank Benutzernamen und Kennwort
  3. Server gibt OK oder NK zurück

Jetzt will ich aber, wenn auch verschlüsselt, keinen Benutzernamen und kein Kennwort einfach durch die Gegend schicken. Meine Idee war folgende:

  1. Auf dem Server sind Benutzername und Kennwort in der Datenbank hinterlegt, wobei das Kennwort gehasht ist
  2. Client meldet sich bei Server, dass er sich authentifizieren will
  3. Server schickt einen einfache String (z.B. eine UUID) an den Client
  4. Der Client hasht sein Kennwort in der selben Weise, wie der Server, und fügt im String Benutzernamen und Kennwort zusammen (thorstenAdsfjlksudSDFAalsj)
  5. Mit dem zusammengefügten Benutzernamen und gehashten Kennwort verschlüsseln wir den vom Server geschickten String (z.B. die UUID)
  6. Den verschlüsselten String schicken wir an den Server zurück
  7. Der Server prüft den verschlüsselten String mit seinem eigenen (er macht das selbe online)
  8. Der Server gibt OK oder NK zurück

Was haltet ihr davon? Eine gute Idee? Hat jemand eine bessere?

KooKooK (Update 1): Ein paar Implementierungen ohne Video

Ich habe überlegt: ich kann leider nicht alles zu dem Projekt aufnehmen. Ich habe noch ein paar Erweiterungen gemacht. Was alles, seht ihr im GitHub-Projekt.

Hier eine Liste:

  • Über die Server.ini kann man den Server jetzt teils konfigurieren
  • Einfaches Logging wurde eingebaut
  • Threads können beendet werden
  • Kompilierungsscript wurde erweitert
  • Unix-Signal-Handling wurde implementiert (TERM und HUP)

Schreibt mir gerne bei Fragen und Anregungen.

FreeBSD-Grundkurs 031: Virtualisierung mit bhyve und vm-bhyve

Wer mit FreeBSD Virtualisierung durchführen möchte, hat mehrere Möglichkeiten: Jails, VirtualBox und QEmu. Mit bhyve bietet FreeBSD aber ein eigenes Virtualisierungsprogramm an, welches sehr einfach mit vm-byhve zu benutzen ist. Wie das geht, zeigt dieses Video.

Virtualisierung mit bhyve und vm-bhyve
Virtualisierung mit bhyve und vm-bhyve

In diesem Beispiel zeige ich, wie man vm-byhve und grub2-bhyve installiert, konfiguriert und ein Debian darin installiert.

Virtualisiertes Debian unter bhyve
Virtualisiertes Debian unter bhyve

Hier einige Kommandos:

# SSH-Verbindung, falls nötig, zum Host aufbauen und darauf achten, dass Escape-Sequenzen von SSH ignoriert werden, da diese sonst nicht an die Console von bhyve geschickt werden können (cu)
ssh -e none $servername

# Installation der benötigten Pakete
pkg install vm-bhyve grub2-bhyve

# ZFS-Dataset erstellen
zfs create storage/bhyve

# /etc/rc.conf bearbeiten
sysrc vm_enable="YES"
sysrc vm_dir="zfs:server/bhyve"

# vm-byhve initialisieren
vm init

# Template kopieren und bearbeiten
cp /usr/local/share/examples/vm-bhyve/debian.conf /server/bhyve/.templates/mydebian.conf

# Switch erstellen und Netzwerk-Interface hinzufügen
vm switch create public
vm switch add public bge0

# ISO-Datei für die Installation von Debian herunterladen
vm iso https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.5.0-amd64-netinst.iso

# Virtuelle Maschine erstellen, Festplattengröße auf 16GB setzen
vm create -t mydebian -s 16g mydebian

# Virtuelle Maschine installieren
vm install -f mydebian debian-11.5.0-amd64-netinst.iso

# Virtuelle Maschinen auflisten (inkl. Status)
vm list

# Vorhandene ISO-Dateien ansehen
vm iso

# Automatischer Start der virtuellen Maschinen
vm_list="vm1 vm2"
vm_delay="5"

Hier geht es zum Video.

wxWidgets-Tutorial 008 – Das erste Programm: Netto-Brutto-Rechner

Um uns zu motivieren, schreiben wir in diesem Video unser erstes eigenes kleines Programm. Ihr könnt mal schauen, ob wxWidgets das Richtige für euch ist und schon, nach dem ersten Erfolgserlebnis, damit ein wenig herumspielen.

Das erste Programm: Netto-Brutto-Rechner
Das erste Programm: Netto-Brutto-Rechner

Und so sieht das Programm aus:

Beispielprogramm
Beispielprogramm

Hier noch der Quelltext:

#include <wx/wx.h>

class BruttoNettoApp : public wxApp {

	public:
		bool OnInit();

};

class BruttoNettoFrame : public wxFrame {

	public:
		BruttoNettoFrame();
	
	private:
		wxPanel *mainPanel;
		wxBoxSizer *mainBoxSizer;
		wxTextCtrl *priceTextCtrl;
		wxStaticText *multiplicatorStaticText;
		wxComboBox *taxComboBox;
		wxButton *calculateButton;
		wxTextCtrl *resultTextCtrl;

};

IMPLEMENT_APP(BruttoNettoApp)

bool BruttoNettoApp::OnInit() {
	BruttoNettoFrame *bruttoNettoFrame = new BruttoNettoFrame;
	bruttoNettoFrame->Show();
	
	SetTopWindow(bruttoNettoFrame);

	return true;
}

BruttoNettoFrame::BruttoNettoFrame() : wxFrame(nullptr, wxID_ANY, "Brutto-Netto-Rechner") {
	mainPanel = new wxPanel(this, wxID_ANY);
	mainBoxSizer = new wxBoxSizer(wxHORIZONTAL);

	priceTextCtrl = new wxTextCtrl(mainPanel, wxID_ANY);
	mainBoxSizer->Add(priceTextCtrl, 1);

	multiplicatorStaticText = new wxStaticText(mainPanel, wxID_ANY, "x");
	mainBoxSizer->Add(multiplicatorStaticText);

	taxComboBox = new wxComboBox(mainPanel, wxID_ANY, "", wxDefaultPosition, wxDefaultSize, 0, NULL, wxCB_READONLY);
	taxComboBox->Append("7%");
	taxComboBox->Append("19%");
	taxComboBox->SetSelection(0);
	mainBoxSizer->Add(taxComboBox);

	calculateButton = new wxButton(mainPanel, wxID_ANY, "=");
	calculateButton->Bind(wxEVT_BUTTON, [this](wxCommandEvent &event) {
		double price = 0.f;
		if(priceTextCtrl->GetValue().ToDouble(&price)) {
			price *= taxComboBox->GetSelection() == 0 ? 1.07 : 1.19;
			resultTextCtrl->SetValue(wxString::Format(_("%lf"), price));
		} else {
			wxMessageBox("Wrong price", "Error");
		}
	});
	mainBoxSizer->Add(calculateButton);
	
	resultTextCtrl = new wxTextCtrl(mainPanel, wxID_ANY, "", wxDefaultPosition, wxDefaultSize, wxTE_READONLY);
	mainBoxSizer->Add(resultTextCtrl, 1);

	mainPanel->SetSizer(mainBoxSizer);
	mainBoxSizer->SetSizeHints(this);

	SetSize(500, -1);

	priceTextCtrl->SetFocus();
	calculateButton->SetDefault();
}

Wer Windows und VisualStudio benutzt, kann auf den Play-Button klicken. Unter anderen Systemen könnte die Kompilierung so aussehen:

c++ NettoBruttoRechner.cpp -o NettoBruttoRechner -std=c++11 `wx-config --libs --cppflags`

Auf die einzelnen Komponenten gehe ich dann Stück für Stück in den nächsten Videos ein. Also keine Angst, falls Ihr hier etwas nicht verstehen solltet, das kommt bald.

Hier geht es zum Video.