Hacker haben offenbar (stets) Zugriff zu ALLEM!...

Volker Bartheld <news2022@bartheld.net> wrote:
On Wed, 16 Nov 2022 00:45:03 +0100, Hanno Foest wrote:
On 15.11.22 21:30, Hergen Lehmann wrote:
Korrektur:  Merkbare sind aber automatisch beträchtlich unsicherer.
Nein, das ist Unsinn.
ObXKCD https://xkcd.com/936/

Genau so schauts aus. Den Comic muß ich mir merken, als
Argumentationsgrundlage.

Wie lange haben wir @work irgendwelche maximalkomplizierten Paßworte
eingegeben, die UNBEDINGT aus Buchstaben (Groß- und Kleinschreibung),
Ziffern und Sonderzeichen bestehen mußte, 16 Stellen oder länger. Der
Benutzername durfte auch nicht enthalten sein und irgendeine Black Box
hat noch nach Substrings gesucht, die aus trivialen Sequenzen (qwertz,
admin, 12345, usw.) besteht.

Natürlich immer hübsch alle zwei-drei Monate ändern, mit maximaler
Differenz zum vorherigen Paßwort (einfach eine Zahl inkrementieren wäre
zu einfach).

Will da jemand unbedingt, dass die Passwörter auf kleinen gelben Klebe-
zetteln an der Unterseite der Tastatur landen? Den mit solchem Unfug
werden Passwörter auf kleine gelbe Zettel unter der Tastatur geschrieben ...

Ergebnis: Man schreibt sich den Kram in eine Datei, macht CTRL-C CTRL-V
und nutzt Chrome Autofill.

Kleine gelbe Klebezettel, sag ich doch ;-)

Inzwischen hatte jemand ein Einsehen und erlaubt den o. g. Ansatz.
\"volker trägt rosa schlüpfer\" nun also endlich möglich. Ein Traum wird
wahr!

Na immerhin.

Man liest sich,
Alex.
--
\"Opportunity is missed by most people because it is dressed in overalls and
looks like work.\" -- Thomas A. Edison
 
Helmut Schellong <rip@schellong.biz> wrote:
On 11/16/2022 08:17, Gerrit Heitsch wrote:
On 11/16/22 08:00, Marcel Mueller wrote:
Am 15.11.22 um 17:34 schrieb Helmut Wabnig:
Passwörter die man sich nicht merken kann
sind auch nix Brauchbares.

In absehbarer Zeit wird eine handelsübliche GraKa jedes Passwort, dass sich ein normal sterblicher Nicht-Savant noch merken kann, knacken können, noch lange bevor Quantencomputer zum Angriff blasen. Dann hat sich das ohnehin erledigt.

Nicht ganz. Denn ausprobieren am Login-Prompt kann die Grafikkarte das nicht, da sind mit Absicht Verzögerungen drin.

Der Trick funktioniert nur wenn du den Hash hast, dann kann die Grafikkarte ihre Geschwindigkeit ausspielen. Aber wenn du den hast ist das jetzt schon problematisch.

Es hat schon seinen Grund warum /etc/shadow (und ähnliches) vom normalen User nicht gelesen werden kann.


Ja; Ich bin seit Jahren sehr erstaunt, mit welcher Dämlichkeit und Denkarmut argumentiert wird.

Wenn ich in der Industrie mit Paßwort geschützte Zugänge programmierte (uC), hatte ich
eine um jeweils 5 Sekunden verzögerte Eingabemöglichkeit programmiert.
Und nach drei Fehlversuchen war Ende im Gelände - Zugang gesperrt, ohne Umgehungsmöglichkeit.
Jeder Fehlversuch wurde in die Fehlerhistorie eingetragen, EEPROM, mit Uhrzeit+Datum.
BrutForce ist da doch praktisch unmöglich.

Sehr ähnlich passiert es bei meinem neuen De-Mail-Zugang.
Es gibt da ein Entsperr-Paßwort.

Standard bei SIM-Karten PINs seit .. 20+ Jahren. Mehrfach falsche PIN in
Folge (IIRC 3x oder so): Karte gesperrt, keine weiteren Versuche. Zum
Entsperren bitte PUK ausgraben und eingeben.

Man liest sich,
Alex.
--
\"Opportunity is missed by most people because it is dressed in overalls and
looks like work.\" -- Thomas A. Edison
 
On 11/20/2022 22:32, Alexander Schreiber wrote:
Helmut Schellong <rip@schellong.biz> wrote:
On 11/16/2022 08:17, Gerrit Heitsch wrote:
On 11/16/22 08:00, Marcel Mueller wrote:
Am 15.11.22 um 17:34 schrieb Helmut Wabnig:
Passwörter die man sich nicht merken kann
sind auch nix Brauchbares.

In absehbarer Zeit wird eine handelsübliche GraKa jedes Passwort, dass sich ein normal sterblicher Nicht-Savant noch merken kann, knacken können, noch lange bevor Quantencomputer zum Angriff blasen. Dann hat sich das ohnehin erledigt.

Nicht ganz. Denn ausprobieren am Login-Prompt kann die Grafikkarte das nicht, da sind mit Absicht Verzögerungen drin.

Der Trick funktioniert nur wenn du den Hash hast, dann kann die Grafikkarte ihre Geschwindigkeit ausspielen. Aber wenn du den hast ist das jetzt schon problematisch.

Es hat schon seinen Grund warum /etc/shadow (und ähnliches) vom normalen User nicht gelesen werden kann.


Ja; Ich bin seit Jahren sehr erstaunt, mit welcher Dämlichkeit und Denkarmut argumentiert wird.

Wenn ich in der Industrie mit Paßwort geschützte Zugänge programmierte (uC), hatte ich
eine um jeweils 5 Sekunden verzögerte Eingabemöglichkeit programmiert.
Und nach drei Fehlversuchen war Ende im Gelände - Zugang gesperrt, ohne Umgehungsmöglichkeit.
Jeder Fehlversuch wurde in die Fehlerhistorie eingetragen, EEPROM, mit Uhrzeit+Datum.
BrutForce ist da doch praktisch unmöglich.

Sehr ähnlich passiert es bei meinem neuen De-Mail-Zugang.
Es gibt da ein Entsperr-Paßwort.

Standard bei SIM-Karten PINs seit .. 20+ Jahren. Mehrfach falsche PIN in
Folge (IIRC 3x oder so): Karte gesperrt, keine weiteren Versuche. Zum
Entsperren bitte PUK ausgraben und eingeben.

Mein vorstehender Text wurde bereits vor Tagen kommentiert.
Und zwar wurde meine Programmierung als idiotische Programmierung eingestuft.
Ich würde damit meine Kollegen ärgern.

Man sieht: Genehm ist nur eine Programmierung, die _scheinbar_ Sicherheit
implementiert; tatsächliche Sicherheit ist unerwünscht - wo kommt man denn damit hin?!

Ich habe seit 1987 stets sichere Konzepte gewählt, die tatsächliche Sicherheit
für mich bewirkten, kühl-professionell.
So habe ich seit 1987 keinen Schaden durch irgendwelche Schad-Software.
Obwohl ich niemals Virenscanner oder ähnlich benutzte.
Das wurde mir nie geglaubt (s.o.).

Die einzige Störung, die ich je hatte, waren ~1000 eMails pro Tag in einem meiner Postfächer.
Die eMails löschte ich mittels eines bish-Skriptes jeweils innerhalb von Sekunden.
Nach wenigen Tagen änderte ich das Paßwort - und das Problem war verschwunden.
Mein Fehler war, daß meine eMail-Paßwörter _damals_ aus nur 8 Kleinbuchstaben bestanden.

Heute konzipiere ich mit gesteigerter Sicherheit.
Beispielsweise verschlüssele ich meine tar-Archive für meine Cloud
kryptisch mit \'rabbit\', \'dragon\' und \'coder\' - bis zu 5-fach mit verschiedenen Keys.
Die entschlüsselt nichts und niemand jemals.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
 
Am 20.11.2022 um 22:32 schrieb Alexander Schreiber:

Standard bei SIM-Karten PINs seit .. 20+ Jahren. Mehrfach falsche PIN in
Folge (IIRC 3x oder so): Karte gesperrt, keine weiteren Versuche. Zum
Entsperren bitte PUK ausgraben und eingeben.

Ja, aber hier gibt es:

a) einen zweiten Faktor (die physische Erreichbarkeit des Telefons)
b) eine zweite Zugriffsebene mit Rücksetzmöglichkeit
c) bei Versagen von b) die Möglichkeit eine Ersatz-SIM zu bekommen

Eine Anmeldemöglichkeit zu einem Benutzeraccount, zu dem ggf. Millionen
Menschen über das Netz Zugang haben, derart zu sichern, daß jegliches
Ausprobieren dazu führt, daß der Zugang

a) dauerhaft
b) unumkehrbar

gesperrt bleibt, wird auf wenig Akzeptanz stoßen.

Bernd
 
On Mon, 21 Nov 2022 00:53:06 +0100, Helmut Schellong <rip@schellong.biz> wrote:

Mein vorstehender Text wurde bereits vor Tagen kommentiert.
Und zwar wurde meine Programmierung als idiotische Programmierung eingestuft.
Ich würde damit meine Kollegen ärgern.

Hmh.

Wenn ich in der Industrie mit Paßwort geschützte Zugänge programmierte (uC), hatte ich
eine um jeweils 5 Sekunden verzögerte Eingabemöglichkeit programmiert.
Und nach drei Fehlversuchen war Ende im Gelände - Zugang gesperrt, ohne Umgehungsmöglichkeit.
Jeder Fehlversuch wurde in die Fehlerhistorie eingetragen, EEPROM, mit Uhrzeit+Datum.
BrutForce ist da doch praktisch unmöglich.

Tatsächlich meine ich der Kommentar zielte daraufhin: durch mutwillig falsche
Eingabe der Zugangsdaten lässt sich dadurch ein erheblicher Schaden provozieren,
nämlich ein dauerhaft gesperrtes System. DOS-Attacke, quasi.

Das ist ein ernstzunehmender Einwand!


Thomas Prufer
 
On 11/21/2022 08:36, Bernd Laengerich wrote:
Am 20.11.2022 um 22:32 schrieb Alexander Schreiber:

Standard bei SIM-Karten PINs seit .. 20+ Jahren. Mehrfach falsche PIN in
Folge (IIRC 3x oder so): Karte gesperrt, keine weiteren Versuche. Zum
Entsperren bitte PUK ausgraben und eingeben.

Ja, aber hier gibt es:

a) einen zweiten Faktor (die physische Erreichbarkeit des Telefons)
b) eine zweite Zugriffsebene mit Rücksetzmöglichkeit
c) bei Versagen von b) die Möglichkeit eine Ersatz-SIM zu bekommen

Eine Anmeldemöglichkeit zu einem Benutzeraccount, zu dem ggf. Millionen Menschen über das Netz Zugang haben, derart zu sichern, daß jegliches Ausprobieren dazu führt, daß der Zugang

a) dauerhaft
b) unumkehrbar

gesperrt bleibt, wird auf wenig Akzeptanz stoßen.

Davon hat allerdings niemand geredet.

Bei meiner Programmierung wird der User über jeden Fehlversuch informiert.
Und nach 30 Stunden ohne weitere Fehlversuche wird wieder freigegeben.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
 
On 11/21/2022 09:31, Thomas Prufer wrote:
On Mon, 21 Nov 2022 00:53:06 +0100, Helmut Schellong <rip@schellong.biz> wrote:

Mein vorstehender Text wurde bereits vor Tagen kommentiert.
Und zwar wurde meine Programmierung als idiotische Programmierung eingestuft.
Ich würde damit meine Kollegen ärgern.

Hmh.

Derjenige bezeichnet aber _pauschal_ fast alles, was ich mache, als idiotisch.

Wenn ich in der Industrie mit Paßwort geschützte Zugänge programmierte (uC), hatte ich
eine um jeweils 5 Sekunden verzögerte Eingabemöglichkeit programmiert.
Und nach drei Fehlversuchen war Ende im Gelände - Zugang gesperrt, ohne Umgehungsmöglichkeit.
Jeder Fehlversuch wurde in die Fehlerhistorie eingetragen, EEPROM, mit Uhrzeit+Datum.
BrutForce ist da doch praktisch unmöglich.


Tatsächlich meine ich der Kommentar zielte daraufhin: durch mutwillig falsche
Eingabe der Zugangsdaten lässt sich dadurch ein erheblicher Schaden provozieren,
nämlich ein dauerhaft gesperrtes System. DOS-Attacke, quasi.

Das ist ein ernstzunehmender Einwand!

Das wäre er, wenn es eine dauerhafte Sperre wäre - /für immer/.
Jedoch nach 30 Stunden ohne weitere Fehlversuche wird wieder freigegeben.

Eine unumgehbare Sperre /für immer/ eines Menüzugangs wäre unsinnig.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
 
Helmut Schellong schrieb:
Thomas Prufer wrote:
Helmut Schellong wrote:

Mein vorstehender Text wurde bereits vor Tagen kommentiert.
Und zwar wurde meine Programmierung als idiotische Programmierung
eingestuft.
Ich würde damit meine Kollegen ärgern.

Hmh.

Derjenige bezeichnet aber _pauschal_ fast alles, was ich mache, als
idiotisch.

Verständlich. Das entspricht angesichts deiner Beschreibungen ja auch
den Tatsachen

Wenn ich in der Industrie mit Paßwort geschützte Zugänge
programmierte (uC), hatte ich
eine um jeweils 5 Sekunden verzögerte Eingabemöglichkeit programmiert.
Und nach drei Fehlversuchen war Ende im Gelände - Zugang gesperrt,
ohne Umgehungsmöglichkeit.
Jeder Fehlversuch wurde in die Fehlerhistorie eingetragen, EEPROM,
mit Uhrzeit+Datum.
BrutForce ist da doch praktisch unmöglich.


Tatsächlich meine ich der Kommentar zielte daraufhin: durch mutwillig
falsche
Eingabe der Zugangsdaten lässt sich dadurch ein erheblicher Schaden
provozieren,
nämlich ein dauerhaft gesperrtes System. DOS-Attacke, quasi.

Das ist ein ernstzunehmender Einwand!


Das wäre er, wenn es eine dauerhafte Sperre wäre - /für immer/.
Jedoch nach 30 Stunden ohne weitere Fehlversuche wird wieder freigegeben.

Hmm, das hast du gerade eben erfunden...
Und selbst, wenn diese Behauptung zuträfe, es wäre ziemlich dämlich,
notwendige Änderungen an Industrieanlagen für 30 Stunden zu blockieren,
nur weil man unfähig ist, vernünftige Zugangssicherungen zu
implementieren. Man könnte ja auch jemanden fragen, der sich mit sowas
auskennt

> Eine unumgehbare Sperre /für immer/ eines Menüzugangs wäre unsinnig.

Richtig. Aber du hast letztens selber behauptet, dass du das stets so
implementiert habest (wobei dir ohnehin kaum noch jemand glauben wird,
dass du \"in der Industrie\" jemals mehr getan hast, als den Ladehof zu
fegen...).

Oder war das in dem Artikel <tl37id$u04f$1@solani.org> mal wieder ein
böser Identitätsdieb, der da schrieb:

| Wenn ich in der Industrie mit Paßwort geschützte Zugänge programmierte
| (uC), hatte ich eine um jeweils 5 Sekunden verzögerte
| Eingabemöglichkeit programmiert.
| Und nach drei Fehlversuchen war Ende im Gelände - Zugang gesperrt,
| ohne Umgehungsmöglichkeit.

Oder haben da alle hier mal wieder deinen \"Kontext\" ignoriert oder nicht
verstanden?

MfG
Rupert
 
Am 21.11.22 um 12:33 schrieb Helmut Schellong:

Standard bei SIM-Karten PINs seit .. 20+ Jahren. Mehrfach falsche PIN in
Folge (IIRC 3x oder so): Karte gesperrt, keine weiteren Versuche. Zum
Entsperren bitte PUK ausgraben und eingeben.

Ja, aber hier gibt es:

a) einen zweiten Faktor (die physische Erreichbarkeit des Telefons)
b) eine zweite Zugriffsebene mit Rücksetzmöglichkeit
c) bei Versagen von b) die Möglichkeit eine Ersatz-SIM zu bekommen

Eine Anmeldemöglichkeit zu einem Benutzeraccount, zu dem ggf.
Millionen Menschen über das Netz Zugang haben, derart zu sichern, daß
jegliches Ausprobieren dazu führt, daß der Zugang

a) dauerhaft
b) unumkehrbar

gesperrt bleibt, wird auf wenig Akzeptanz stoßen.

Davon hat allerdings niemand geredet.

Ein gewisser Helmut Schellong in <tl37id$u04f$1@solani.org>:

\"Und nach drei Fehlversuchen war Ende im Gelände - Zugang gesperrt, ohne
Umgehungsmöglichkeit.\"

Was soll \"ohne Umgehungsmöglichkeit\" anderes heißen als dauerhaft und
unumkehrbar?

Bei meiner Programmierung wird der User über jeden Fehlversuch informiert.
Und nach 30 Stunden ohne weitere Fehlversuche wird wieder freigegeben.

Die lediglich für 30 Stunden ausgesperrten Kollegen werden sich bedanken.

Hanno

--
The modern conservative is engaged in one of man\'s oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith
 
Am 20.11.22 um 22:32 schrieb Alexander Schreiber:

Wenn ich in der Industrie mit Paßwort geschützte Zugänge programmierte (uC), hatte ich
eine um jeweils 5 Sekunden verzögerte Eingabemöglichkeit programmiert.
Und nach drei Fehlversuchen war Ende im Gelände - Zugang gesperrt, ohne Umgehungsmöglichkeit.
Jeder Fehlversuch wurde in die Fehlerhistorie eingetragen, EEPROM, mit Uhrzeit+Datum.
BrutForce ist da doch praktisch unmöglich.

Sehr ähnlich passiert es bei meinem neuen De-Mail-Zugang.
Es gibt da ein Entsperr-Paßwort.

Standard bei SIM-Karten PINs seit .. 20+ Jahren. Mehrfach falsche PIN in
Folge (IIRC 3x oder so): Karte gesperrt, keine weiteren Versuche. Zum
Entsperren bitte PUK ausgraben und eingeben.

Kleiner Unterschied: An deinem Telefon hat niemand anderes als du was zu
suchen. der obige Vorgang ist im Wesentlichen ein Schutz bei Verlust.

Industrieanlagen hingegen dürften eher selten verlorengehen, die stehen
meist rechts ortsfest irgendwo rum, und eine gewisse Anzahl Mitarbeiter
hat Zugang. Entsprechend gibt es da ein entsprechendes Potential, durch
absichtliche oder unabsichtliche Fehleingaben die Anlage unbedienbar zu
machen, was eher selten im Betriebsinteresse sein dürfte.

Hanno

--
The modern conservative is engaged in one of man\'s oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith
 
On 11/21/2022 14:50, Rupert Haselbeck wrote:
Helmut Schellong schrieb:
Thomas Prufer wrote:
Helmut Schellong wrote:

Mein vorstehender Text wurde bereits vor Tagen kommentiert.
Und zwar wurde meine Programmierung als idiotische Programmierung eingestuft.
Ich würde damit meine Kollegen ärgern.

Hmh.

Derjenige bezeichnet aber _pauschal_ fast alles, was ich mache, als idiotisch.

Verständlich. Das entspricht angesichts deiner Beschreibungen ja auch den Tatsachen

Nein, ich hatte den Auftrag, ein Geheimmenü wirksam zu schützen.
Und meine Lösung wurde angenommen und bestätigt.

Wenn ich in der Industrie mit Paßwort geschützte Zugänge programmierte (uC), hatte ich
eine um jeweils 5 Sekunden verzögerte Eingabemöglichkeit programmiert.
Und nach drei Fehlversuchen war Ende im Gelände - Zugang gesperrt, ohne Umgehungsmöglichkeit.
Jeder Fehlversuch wurde in die Fehlerhistorie eingetragen, EEPROM, mit Uhrzeit+Datum.
BrutForce ist da doch praktisch unmöglich.


Tatsächlich meine ich der Kommentar zielte daraufhin: durch mutwillig falsche
Eingabe der Zugangsdaten lässt sich dadurch ein erheblicher Schaden provozieren,
nämlich ein dauerhaft gesperrtes System. DOS-Attacke, quasi.

Das ist ein ernstzunehmender Einwand!


Das wäre er, wenn es eine dauerhafte Sperre wäre - /für immer/.
Jedoch nach 30 Stunden ohne weitere Fehlversuche wird wieder freigegeben.

Hmm, das hast du gerade eben erfunden...

Und nachfolgend stimmst Du _meiner_ Aussage zu, daß eine Sperre /für immer/ unsinnig wäre.
Normale, einfache Logik ist Dir offenbar fremd.

> Und selbst, wenn diese Behauptung zuträfe, es wäre ziemlich dämlich, notwendige Änderungen an Industrieanlagen für 30 Stunden zu blockieren, nur weil man unfähig ist, vernünftige Zugangssicherungen zu implementieren. Man könnte ja auch jemanden fragen, der sich mit sowas auskennt

Das ist falsch; ich sprach schon vor Tagen von der Sperrung eines Menüs.
Ein Menü von vielleicht 40.
Die Steuerung und Kontrolle der gesamten Anlage läuft doch trotz Sperrung eines Menüs weiter!

Eine unumgehbare Sperre /für immer/ eines Menüzugangs wäre unsinnig.

Richtig. Aber du hast letztens selber behauptet, dass du das stets so implementiert habest (wobei dir ohnehin kaum noch jemand glauben wird, dass du \"in der Industrie\" jemals mehr getan hast, als den Ladehof zu fegen...).

Es ist eindeutig erkennbar, daß Du hier wieder einmal blindes, unlogisches Pauschal-Bashing betreibst.

Oder war das in dem Artikel <tl37id$u04f$1@solani.org> mal wieder ein böser Identitätsdieb, der da schrieb:

| Wenn ich in der Industrie mit Paßwort geschützte Zugänge programmierte | (uC), hatte ich eine um jeweils 5 Sekunden verzögerte
| Eingabemöglichkeit programmiert.
| Und nach drei Fehlversuchen war Ende im Gelände - Zugang gesperrt,
| ohne Umgehungsmöglichkeit.

Oder haben da alle hier mal wieder deinen \"Kontext\" ignoriert oder nicht verstanden?

Ja, natürlich; Es wurde abermals Deutsch nicht richtig verstanden.

Ich beschreibe eine Eingabemöglichkeit mit jeweils 5 Sekunden Verzögerung.
Und unmittelbar folgend, daß _damit_ nach drei Fehlversuchen /Ende im Gelände/ ist --> Sperre.

Das sagt in keiner Weise aus, das da eine /ewige/ Eingabesperre gesetzt wird.
Weiterhin ist keine Aussage vorhanden, daß Steuerung und Kontrolle der gesamten Industrieanlage gestoppt werden.
Dies wurde einfach hinzugelogen, um Mobbing betreiben zu können.


Es fehlt hier überwiegend die Kenntnis, wie SW für größere Industrieanlagen konzeptioniert sein muß.
Das wichtigste Merkmal ist, daß es eine MASCHINE per Interrupt geben muß, die _immer_ laufen muß!
Auch, wenn in einem Menü gearbeitet wird.
Auch, wenn umfangreiche Ausgaben vorgenommen werden.
Auch, wenn umfangreiche Kommunikation läuft (><~100000 Byte).
Siehe unten \'MU.req\' (Requests).

Es ist folglich idiotisch, wegen einer Eingabensperre auch Kontrolle und Steuerung
der Industrieanlage als gestoppt anzunehmen!

=======================================================================================#pragma register(12)
__nosavereg
__interrupt void Int_TBTimer(void) /* 18-bit Time Base Timer, alle 4.096 ms */
{
TBTC_TBOF=0; /* IRPT-Auslöser */
WD_RESET;
TBTleds();
if (FL_CS==0) MU.flashing=3;
//if (MU.getkeycode&&--MU.getkeycode==0);
if (EAbit.rd1can) RD1.flg.nocan=1;
else {
if (RD1.flg.nocan) RD1_nocan();
if (RD1.flg.txlcd) RD1_txlcd();
else if ((RD1.cmptmr++&63)==0) MU.req|=REQ_RD1;
}

CK_CTS(UNE,e,E);
CK_CTS(UNI,i,I);

if (TBT._1s==0) TBTstart(), MU.req|=REQ_RDRTC;

if (Comm.Uer.n>0) Read_Uring(UNE);
if (Comm.Uir.n>0) Read_Uring(UNI);


/* 244 * 4.096ms = 0.999424s ~ 1s */
switch (TBT._1s) {
default :
if (!TBT.can_end) {
/* CAN communication with connected devices */
TBT_CANcomm();
}
else TBTcandev_str(0);
//0,64,128,192
if ((TBT._1s&63)==2) ADC.tbt=NS_ADC;
if (ADC.tbt) ADCS1_STRT=1, --ADC.tbt;
else if (ADC.s||ADC.v) ADC.s=ADC.v=0, Init_ADC();
Mess_read_buffs();
break;
case 225:
if (ADC.handler==0) Init_ADC();
ADC.handler=0;
if (Can.bus_off_timer > 0) Can.bus_off_timer--;
else if (Can.bus_off_timer_start) {
Can.bus_off_timer_start= 0;
CSR0= BUS_IRPT_EN; // node transition IRPT enabled
MU.req|=REQ_INITCAN; MU.req_ican|=1;
}
if (Can1.bus_off_timer > 0) Can1.bus_off_timer--;
else if (Can1.bus_off_timer_start) {
Can1.bus_off_timer_start= 0;
CSR1= BUS_IRPT_EN; // node transition IRPT enabled
MU.req|=REQ_INITCAN; MU.req_ican|=2;
}
TBT_check_changed_vars(\'s\');
break;
case 226: if (Modem[0].strt>1) TBTmodem(&Modem[0]);
if (Modem[1].strt>1) TBTmodem(&Modem[1]);
TBT_check_login_timeout();
break;
case 227:
TBTstart_bt_sl_clock_time();
TBTbattest();
TBTbtstore();
break;
case 228: TBTstarkladung();
TBThandsyst(); break;
case 229: if (RDP.enable&&Can.RDP.anz) RDP_tbt();
TBTschwellen_check(); break;
case 230: /*** Auswertung der Isolationsspannung UES ***/
# define K(k) TBTriso(k);
Kx()
# undef K
break;
case 231: /*** Prüfung der Iglr-Verteilung ***/
TBT_reclast(); break;
case 232: /*** Netzspannungen (Karte MMB) ***/
TBTnetz();
TBT_ah();
TBT_temp();
TBT_unsym();
TBT_udiff();
break;
case 233:
TBT_lvdpld();
MU_setevent();
TBTkpzcalc();
break;
case 234: /*** Temperaturkomp. der Ausgangsspannung ***/
/*** Ladestrombegrenzung Ibatt ==> Ured ***/
/*** Sollwert Spannung ***/
TBT_TsenCk();
TBT_tkomp_ured_ugsoll(); break;
case 235: /*** Auswertung der CAN-Kontakte ***/
TBTregis();
TBTcankontakte(); break;
case 236: /*** Auswertung der Digitaleingänge ***/
TBTdigitalinputs();
break;
case 237: TBTgeneral_thres();
TBTbatt_checks();
TBTgegenz();
break;
case 238: TBTalarm_inh_dis(); break;
case 239: TBTsnmp_events(); break;
case 240: TBTrec_events(); break;
case 241: TBTset_events(); break;
case 242: /*** Auswertung Gerätestatus und Zuordnung zu den Meldungen ***/
TBT_set_outputs();
TBTcandev_str(1);
break;
case 243: TBTend();
if (TBT.mkcrc>1) --TBT.mkcrc;
if (MU.flashing&&FL_CS==1) --MU.flashing;
if (Sys.cycles<15) ++Sys.cycles;
break;
}
if (TBT._1s>=225) {
if (Comm.Uer.n>2) Read_Uring(UNE);
if (Comm.Uir.n>2) Read_Uring(UNI);
}
if (++TBT._1s>=244) TBT._1s=0, TBT.can_end=0;
TBTC_TBOF=0; /* IRPT-Auslöser */
return;
}
#pragma noregister
=======================================================================================

--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
 
On 11/21/2022 14:59, Hanno Foest wrote:
Am 21.11.22 um 12:33 schrieb Helmut Schellong:

Standard bei SIM-Karten PINs seit .. 20+ Jahren. Mehrfach falsche PIN in
Folge (IIRC 3x oder so): Karte gesperrt, keine weiteren Versuche. Zum
Entsperren bitte PUK ausgraben und eingeben.

Ja, aber hier gibt es:

a) einen zweiten Faktor (die physische Erreichbarkeit des Telefons)
b) eine zweite Zugriffsebene mit Rücksetzmöglichkeit
c) bei Versagen von b) die Möglichkeit eine Ersatz-SIM zu bekommen

Eine Anmeldemöglichkeit zu einem Benutzeraccount, zu dem ggf. Millionen Menschen über das Netz Zugang haben, derart zu sichern, daß jegliches Ausprobieren dazu führt, daß der Zugang

a) dauerhaft
b) unumkehrbar

gesperrt bleibt, wird auf wenig Akzeptanz stoßen.

Davon hat allerdings niemand geredet.

Ein gewisser Helmut Schellong in <tl37id$u04f$1@solani.org>:

\"Und nach drei Fehlversuchen war Ende im Gelände - Zugang gesperrt, ohne Umgehungsmöglichkeit.\"

Was soll \"ohne Umgehungsmöglichkeit\" anderes heißen als dauerhaft und unumkehrbar?

Ich beschreibe eine Eingabemöglichkeit mit jeweils 5 Sekunden Verzögerung.
Und unmittelbar folgend, daß _damit_ nach drei Fehlversuchen /Ende im Gelände/ ist --> Sperre.

\"ohne Umgehungsmöglichkeit\":
----------------------------
Wenn sich die Software in der 30-stündigen Verzögerung befindet, kann dieser Zustand
_nur_ durch Auslöten des EEPROMs und Einlöten des EEPROMs nach entsprechend geändertem
Inhalt beendet werden.
_Nur_ ich selbst hätte das vornehmen können.

Bei meiner Programmierung wird der User über jeden Fehlversuch informiert.
Und nach 30 Stunden ohne weitere Fehlversuche wird wieder freigegeben.

Die lediglich für 30 Stunden ausgesperrten Kollegen werden sich bedanken.

Logischerweise bei meinen Vorgesetzten, die eine solche Programmierung von mir verlangten.
Eine Kontaktaufnahme direkt mit mir, als sachbearbeitender Entwickler, war nicht möglich.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
 
Wolfgang Allinger schrieb:
eMail und vermutetes Passwort: Falsches Passwort!
eMail und \"Passwort vergessen\": BenutzerID unbekannt!
eMail und \"Neuer Account\": BenutzerID bereits vergeben!

Das ist die übliche Kniefickerei auf vielen Seiten!
Scheissskriptkiddies ... na immerhin 5 S :]

Weltweit gibt es 10+Mio Webshops. Jeder ist irgendwie anders.
Jeder kann irgendwas nicht, was nervt. Und mindestens ein was
ist total schräg. Als wolle man absichtlich Scheisse durch-
permutieren.

IT selber ist *die* Cash Cow. Meine Verschwörungstheorie ist,
dass das eine Verschwörung ist :-].
Arbeitsbeschaffungsmassnahme und Geldverschwendung ohne Ende.
Dazu kommt die Abschottung wie bei den Juristen, Ärzten etc.

Autos wurden zuerst auch einzeln angefertigt und es gab
tausende von kleinen Firmen. Das hat sich schnell gelegt.
In der IT... ich frag mich, bald 60(!) Jahre nach der PDP-8
wird da immer noch einzeln rumgestümpert.

--
mfg Rolf Bombach
 
Gregor Szaktilla schrieb:
Am 15.11.22 um 18:47 schrieb Andreas Graebe:
Wenn ein Passwort zwangsweise Sonderzeichen, Zahlen, Groß- und
Kleinschreibung enthalten _muß_, schränkt das nicht die Anzahl der
möglichen Kombinationen eher ein?

Jein :)

Ich denke, dass es dabei darum geht, lexikalische Passwörter zu verhindern. Die Möglichkeiten werden zwar eingeschränkt, aber es wird erheblich erschwert, ein Passwort zu erraten.

Sehe ich auch so. Der Nutzer wird damit quasi gezwungen,
einen Textfluss erratisch zu unterbrechen. Schwachstelle
ist ja üblicherweise, dass einfache Wörter genommen werden.

Passphrasen sind ebenso gefährlich, da die längst in den
Listen aufgeführt werden. Anfangsbuchstaben von Gedichten,
insbesondere aus Pflichtstoff aus der Schule, sind alle
schon in den Listen und daher speziell dämlich.
Fest gemauert in der Erden...

--
mfg Rolf Bombach
 
Helmut Schellong schrieb:
Wenn ich in der Industrie mit Paßwort geschützte Zugänge programmierte (uC), hatte ich
eine um jeweils 5 Sekunden verzögerte Eingabemöglichkeit programmiert.
Und nach drei Fehlversuchen war Ende im Gelände - Zugang gesperrt, ohne Umgehungsmöglichkeit.
Jeder Fehlversuch wurde in die Fehlerhistorie eingetragen, EEPROM, mit Uhrzeit+Datum.

Das war der Trick, um unter RSX-11 ein Passwort rauszufinden.
Einfach die Konsole des Sysadmins starten und dieses
Fehlversuch-Logging aktivieren. War eh immer auf einem
DECwriter.
Dort einfach auf die \"Fehlversuche\" achten. Da stand da etwa

User \"MUELLER\" tried \"AudiQuattrp\"

Rest bleibt der Fantasie des Lesers überlassen.

--
mfg Rolf Bombach
 
Hanno Foest schrieb:

Industrieanlagen hingegen dürften eher selten verlorengehen, die stehen meist
rechts ortsfest irgendwo rum, und eine gewisse Anzahl Mitarbeiter hat Zugang.

Diese Sicherheitsmassnahme hat mir nie gefallen und hat mir auch viele
Diskussionen eingehandelt. In grösseren Betrieben wird man nie endgültig
rauskriegen, wer alles Zugang hat.
Die IT war äusserst pingelig mit Accounts und Passwörtern etc. Auf der
andern Seite hielten sie im Labor rumstehende PCs, eingeloggt auf einem
\"allgemeinen\" Account für keine Sicherheitslücke. Begründung: Kommt ja
sonst eh keiner rein. Hä?
Ich habe z.B. nie rausgekriegt, wer alles Zugang zu \"meinem\" Laserlabor
hat. Vordergründig nur einige wenige Mitarbeiter. Und dann natürlich
\"die Elektriker\", da ein Verteiler irgendwo angedübelt ist. Und
Mitglieder der Gaswarntruppe (WTF?). Und Labor-Pikettdienst des
Gebäudes. Gas Wasser Scheisse, möglicherweise. Heizung Lüftung Klima,
eher weniger, da die nie reinkamen, aber ist man sicher? Und die
Sicherheitszentrale. Feuerwehr. SU. Und und und.

Ich hab periodisch in der Liste immer wieder Gruppen und Individuen
streichen lassen und dann einfach gewartet, bis jemand mault.
Und dann genauer gefragt, ob und warum denn der Betreffende meint,
dass er da Zutritt haben müsste. Ad infinitum.

--
mfg Rolf Bombach
 
On 11/26/2022 22:20, Rolf Bombach wrote:
Wolfgang Allinger schrieb:

eMail und vermutetes Passwort: Falsches Passwort!
eMail und \"Passwort vergessen\": BenutzerID unbekannt!
eMail und \"Neuer Account\": BenutzerID bereits vergeben!

Das ist die übliche Kniefickerei auf vielen Seiten!
Scheissskriptkiddies   ... na immerhin 5 S :]

Weltweit gibt es 10+Mio Webshops. Jeder ist irgendwie anders.
Jeder kann irgendwas nicht, was nervt. Und mindestens ein was
ist total schräg. Als wolle man absichtlich Scheisse durch-
permutieren.

Es muß beachtet werden, daß die obigen Funktionen keinerlei
Verknüpfung untereinander aufweisen dürfen.
Beispiel:
Wenn die Zugangsdaten beim Login falsch waren, darf die Fehlermeldung
_nicht_ die Information enthalten, daß das Passwort falsch ist
oder daß der Benutzername unbekannt ist!
Es muß _nach beiden Eingaben_ gemeldet werden, daß die Zugangsdaten nicht korrekt sind.
Es darf also keinerlei Information gegeben werden, die über diejenige Information
hinausgeht, daß die Gesamtaktion wegen Eingabe unkorrekter Daten fehlgeschlagen ist.

IT selber ist *die* Cash Cow. Meine Verschwörungstheorie ist,
dass das eine Verschwörung ist :-].
Arbeitsbeschaffungsmassnahme und Geldverschwendung ohne Ende.
Dazu kommt die Abschottung wie bei den Juristen, Ärzten etc.

Ich sah mal eine Statistik:
Steigerung der Effizienz von 1920..1976 (ungefähr):
in der Produktion: 1080%
im Büro: 76%


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
 
On 11/26/2022 22:25, Rolf Bombach wrote:
Gregor Szaktilla schrieb:
Am 15.11.22 um 18:47 schrieb Andreas Graebe:
Wenn ein Passwort zwangsweise Sonderzeichen, Zahlen, Groß- und
Kleinschreibung enthalten _muß_, schränkt das nicht die Anzahl der
möglichen Kombinationen eher ein?

Jein :)

Ich denke, dass es dabei darum geht, lexikalische Passwörter zu verhindern. Die Möglichkeiten werden zwar eingeschränkt, aber es wird erheblich erschwert, ein Passwort zu erraten.

Sehe ich auch so. Der Nutzer wird damit quasi gezwungen,
einen Textfluss erratisch zu unterbrechen. Schwachstelle
ist ja üblicherweise, dass einfache Wörter genommen werden.

Passphrasen sind ebenso gefährlich, da die längst in den
Listen aufgeführt werden. Anfangsbuchstaben von Gedichten,
insbesondere aus Pflichtstoff aus der Schule, sind alle
schon in den Listen und daher speziell dämlich.
Fest gemauert in der Erden...

Ich sah im Internet viele, viele, viele Tips für sichere Paßwörter, die allesamt
(dringend) empfehlen, eine Folge von normalen Wörtern hintereinander oder deren
Anfangsbuchstaben zur Bildung des Paßwortes zu verwenden, weil solch ein Paßwort
leicht merkbar ist.

Auch in dieser Newsgroup wurden diese Tips für sichere Paßwörter empfohlen - aber hallo, Hallo, HALLO!
Man hatte sich offensichtlich an den Tips aus dem Internet orientiert.
Die jedoch grausam falsch und dämlich sind, so wie \'dähmlich\' dämlich ist.

Es ist in Wirklichkeit kein Vorteil, sich ein Paßwort gut merken zu können, weil
spätestens bei 10 Paßwörtern die Zuordnung Paßwort<>Konto nicht mehr sicher merkbar ist.
Ich habe etwa 150 Paßwörter im Internet.
Auch, weil pro Provider mehrere Paßwörter notwendig sind.

Garantiert am sichersten sind Paßwortsequenzen wie die folgenden:

%/ZI2Ts{n|]PpL3Nut_gX\"!m80<9HYE~.*iMl$@?kQ4,d&K+5^eba[rzC6#w\\R;q
0\\W`&G~61Y4xz{tcF8g^9%Dfmsr_@\"|U3B:)p+HjhOAkIel5}-o7MV)qSL2uy*da
sW\"7Vp3}/MX#wrxNG@tKymIn$:O8.5[o~*bL)<aSqFY>DE\\Jh]BlH{4?jfTC`9u-

wenn der Zeichensatz ascii zugrunde gelegt wird.
http://www.sicherespasswort.com/


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
 
On 11/26/2022 22:41, Rolf Bombach wrote:
Helmut Schellong schrieb:

Wenn ich in der Industrie mit Paßwort geschützte Zugänge programmierte (uC), hatte ich
eine um jeweils 5 Sekunden verzögerte Eingabemöglichkeit programmiert.
Und nach drei Fehlversuchen war Ende im Gelände - Zugang gesperrt, ohne Umgehungsmöglichkeit.
Jeder Fehlversuch wurde in die Fehlerhistorie eingetragen, EEPROM, mit Uhrzeit+Datum.

Das war der Trick, um unter RSX-11 ein Passwort rauszufinden.
Einfach die Konsole des Sysadmins starten und dieses
Fehlversuch-Logging aktivieren. War eh immer auf einem
DECwriter.
Dort einfach auf die \"Fehlversuche\" achten. Da stand da etwa

User \"MUELLER\" tried \"AudiQuattrp\"

Rest bleibt der Fantasie des Lesers überlassen.

Ein größerer Schwachsinn, als \'User \"MUELLER\" tried \"AudiQuattrp\"\' in eine
Log-Datei zu schreiben, ist für mich unvorstellbar.

Ich hatte selbstverständlich nur eine Usergruppennummer (s.u.) und das betroffene
Geheim-Menü (Titel) eingetragen.

Beim uC kann meist gar nicht mit User und Pass programmiert werden.
Die Geräte haben fast alle nur 4 Tasten (Up Down Enter Esc) und es können daher
praktisch keine Zeichenketten eingegeben werden.
Es konnten nur Zahlen von 0 bis 999 eingegeben werden per Up/Down.
Up/Down hatten 4 sich automatisch steigernde Inc/Dec-Geschwindigkeiten.

Für die Geheim-Menüs hatte ich _zwei_ Zahlen je 100..999 programmiert.
Nach Eingabe der ersten Zahl mußte das Menü per Esc verlassen und danach
erneut betreten werden, innerhalb eines gewissen Zeitraums.

Es gab ein Gerät mit 6 Tasten. Da war String-Eingabe möglich.

Das LCD gestattete die Selbstdefinition von 4 Zeichen.
Ich programmierte damit für 4-Tasten-Geräte \'Delete\', \'Insert\', etc.
Für die Kunden war das jedoch zu /anspruchsvoll/.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
 
On 11/26/22 22:55, Rolf Bombach wrote:
Hanno Foest schrieb:

Industrieanlagen hingegen dürften eher selten verlorengehen, die
stehen meist rechts ortsfest irgendwo rum, und eine gewisse Anzahl
Mitarbeiter hat Zugang.

Diese Sicherheitsmassnahme hat mir nie gefallen und hat mir auch viele
Diskussionen eingehandelt. In grösseren Betrieben wird man nie endgültig
rauskriegen, wer alles Zugang hat.
Die IT war äusserst pingelig mit Accounts und Passwörtern etc. Auf der
andern Seite hielten sie im Labor rumstehende PCs, eingeloggt auf einem
\"allgemeinen\" Account für keine Sicherheitslücke. Begründung: Kommt ja
sonst eh keiner rein. Hä?
Ich habe z.B. nie rausgekriegt, wer alles Zugang zu \"meinem\" Laserlabor
hat. Vordergründig nur einige wenige Mitarbeiter. Und dann natürlich
\"die Elektriker\", da ein Verteiler irgendwo angedübelt ist. Und
Mitglieder der Gaswarntruppe (WTF?). Und Labor-Pikettdienst des
Gebäudes. Gas Wasser Scheisse, möglicherweise. Heizung Lüftung Klima,
eher weniger, da die nie reinkamen, aber ist man sicher? Und die
Sicherheitszentrale. Feuerwehr. SU. Und und und.

Putzdienst nicht vergessen. Die haben oft mehr Zugangsrechte als alle
anderen.

Gerrit
 

Welcome to EDABoard.com

Sponsor

Back
Top