Re: [Metalab] nanolack ... die zweite,
Naja. Bein den herkömlichen auth methoden, z.b. CHAP, braucht man das plaintext Passwort. Und das Passwort symmetrisch verschlüsselt zu speichern hat das Problem dass der Schlüssel auch nicht schwieriger zu klauen ist, als die Datenbank. Ein textfile für die Radius auth zu nehmen ist ungeschickt und wartungsintensiv. Martin Schürrer <martin@schuerrer.org> wrote:
Weil ich privat gefragt wurde ob es wirklich nötig sei die User von ACW zu informieren:
Ja, dass er das File geschickt hat sehe ich nicht als das Problem.
Das Problem ist, a) dass der Provider die Passwörter im plaintext speichert, b) dass diese Passwörter in einem File das offensichtlich von Menschen gelesen/geändert wird stehen.
Darüber muss man die User informieren, sie haben IMO ein Recht das zu erfahren.
Generell sollte man solche Sicherheitsprobleme nicht einfach verharmlosen. Ist bisschen inkonsequent wenn ansonsten "der typische Metalaber" gegen VDS ist.
Also hat schon jemand den Usern geschrieben?
Cheers, Martin
2012/4/23 overflo <flo@tekstix.com>
ach. du. scheisse.
das könnt eine overflo aktion gewesen sein.
:* -flo
______________________________**_________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/**mailman/listinfo/metalab<https://lists.metalab.at/mailman/listinfo/metalab>
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab
Ich kenne mich nicht mit ISP Software aus, aber in ein File das offensichtlich manuell bearbeitet wird plaintext Passwörter zu speichern ist inakzeptabel für einen ISP. Die PWs symmetrisch zu verschlüsseln würde z.B. das Problem das wir hier diskutieren gelöst haben. Cheers, Martin 2012/4/23 Michael Lausch <mla@lausch.at>
Naja. Bein den herkömlichen auth methoden, z.b. CHAP, braucht man das plaintext Passwort. Und das Passwort symmetrisch verschlüsselt zu speichern hat das Problem dass der Schlüssel auch nicht schwieriger zu klauen ist, als die Datenbank. Ein textfile für die Radius auth zu nehmen ist ungeschickt und wartungsintensiv.
Martin Schürrer <martin@schuerrer.org> wrote:
Weil ich privat gefragt wurde ob es wirklich nötig sei die User von ACW zu informieren:
Ja, dass er das File geschickt hat sehe ich nicht als das Problem.
Das Problem ist, a) dass der Provider die Passwörter im plaintext speichert, b) dass diese Passwörter in einem File das offensichtlich von Menschen gelesen/geändert wird stehen.
Darüber muss man die User informieren, sie haben IMO ein Recht das zu erfahren.
Generell sollte man solche Sicherheitsprobleme nicht einfach verharmlosen. Ist bisschen inkonsequent wenn ansonsten "der typische Metalaber" gegen VDS ist.
Also hat schon jemand den Usern geschrieben?
Cheers, Martin
2012/4/23 overflo <flo@tekstix.com>
ach. du. scheisse.
das könnt eine overflo aktion gewesen sein.
:* -flo
______________________________**_________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/**mailman/listinfo/metalab<https://lists.metalab.at/mailman/listinfo/metalab>
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-04-23 23:14, Martin Schürrer wrote:
Ich kenne mich nicht mit ISP Software aus, aber in ein File das offensichtlich manuell bearbeitet wird plaintext Passwörter zu speichern ist inakzeptabel für einen ISP.
Ich zwar auch nicht aber was ich aus anderen Firmen so kenne wundert mich das eigentlich nicht... leider...
Die PWs symmetrisch zu verschlüsseln würde z.B. das Problem das wir hier diskutieren gelöst haben.
Cheers, Martin
2012/4/23 Michael Lausch <mla@lausch.at>
Naja. Bein den herkömlichen auth methoden, z.b. CHAP, braucht man das plaintext Passwort. Und das Passwort symmetrisch verschlüsselt zu speichern hat das Problem dass der Schlüssel auch nicht schwieriger zu klauen ist, als die Datenbank. Ein textfile für die Radius auth zu nehmen ist ungeschickt und wartungsintensiv.
Martin Schürrer <martin@schuerrer.org> wrote:
Weil ich privat gefragt wurde ob es wirklich nötig sei die User von ACW zu informieren:
Ja, dass er das File geschickt hat sehe ich nicht als das Problem.
Das Problem ist, a) dass der Provider die Passwörter im plaintext speichert, b) dass diese Passwörter in einem File das offensichtlich von Menschen gelesen/geändert wird stehen.
Darüber muss man die User informieren, sie haben IMO ein Recht das zu erfahren.
Generell sollte man solche Sicherheitsprobleme nicht einfach verharmlosen. Ist bisschen inkonsequent wenn ansonsten "der typische Metalaber" gegen VDS ist.
Also hat schon jemand den Usern geschrieben?
Cheers, Martin
2012/4/23 overflo <flo@tekstix.com>
ach. du. scheisse.
das könnt eine overflo aktion gewesen sein.
:* -flo
______________________________**_________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/**mailman/listinfo/metalab<https://lists.metalab.at/mailman/listinfo/metalab>
_______________________________________________
Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPldUTAAoJEAhgHfpCPcybVjkIAITLV7IJjfTMGfoc/m7FxCRy wucl6XyAD05uEuS049MY5cyqlwX0HCp3bXUCiejq3Z8QStiSB6AzThGvxZTjmHeQ NRW7sExzoBDkAQOLMiTomIlu5YCnXX9Xy1iEu3ZZqI7JWktj4yVklrVHcPGrZP+C HtV38iv9K4TwSWlMvV4soEFAPUj88oSlHvrJpaFwy9SCLVzilq6f69Z7WJGjVZas //d7j0PXYMI/3Zr/V79YXwfDEz73nB5tH9AhqbJwv2jejiYIcWq6orCMIkiQn3VV 9ZIhdpmWGOLR3Z4zh4Gh5N26ABGVb6uAt6BzAHCkiSj3hxFkATSDuMhpbS6m8S0= =hHKw -----END PGP SIGNATURE-----
On 2012-04-24 00:17, Sebastian Bachmann wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-23 23:14, Martin Schürrer wrote:
Ich kenne mich nicht mit ISP Software aus, aber in ein File das offensichtlich manuell bearbeitet wird plaintext Passwörter zu speichern ist inakzeptabel für einen ISP.
Ich zwar auch nicht aber was ich aus anderen Firmen so kenne wundert mich das eigentlich nicht... leider...
Das file ist ein standard format, das fuer alle (die ich kenne) RADIUS server verwendet wird. Es kann ja auch ein export aus einer DB sein. Dagegen sprechen allerdings die kommentare.
Die PWs symmetrisch zu verschlüsseln würde z.B. das Problem das wir hier diskutieren gelöst haben.
Das haette GPG oder SMIME oder was auch immer fuer vertrauliche emails verwendet werden muss, auch getan. und PGP/GPG/SMIMEes haette den vorteil, dass es auch fuer alle anderen emails auch "funktioniert". Wie z.B. das excel file mit den kontonummern. Die verwendung von email ohne SMIME/PGP um vertrauliche daten durch die gegend zu schicken hat mich immer schon gewundert. Vor allem weil die Empfaenger alles glauben was in so einer email rumgeschickt wird, wenn der absender im organigram hoch genug steht. und die eigenschaft von outlook die absender adresse so gut zu verstecken, koennen einem unterhaltsame minuten beschehren.
Hi!
und die eigenschaft von outlook die absender adresse so gut zu verstecken, koennen einem unterhaltsame minuten beschehren.
Danke, hatte ich schon. Hab hier meinen selbstgeschriebenen Mailserver in Betrieb (für den vom Internet getrennten Shopfloor-Bereich zur Statusüberwachung und automatischen Verarbeitung von Warnmails). Ein Teil der Mails wird dann an den zentralen Exchange weitergespoolt. Im ersten Live-Test hatte ich die Envelope-Header richtig, die Content-Header waren Müll. Exchange hat da erstmal ganz große Augen gemacht, dran rumgegurkt und dann kompletten Ramsch an die Outlook-Clients weitergeleitet. Und jetzt erklär mal einem User, wie er die restlichen Mailheader kopieren und weiterleiten kann, damit ich die Mail-ID seh und das Problem fixen kann... (Lustigerweise meinten Spam- und Virenerkenner am Exchange beide "jaja, das passt schon"). LG Rene
Teilnehmer (4)
-
Martin Schürrer -
Michael Lausch -
rene.schickbauer＠magnapowertrain.com -
Sebastian Bachmann