Nach Hause
Top.Mail.Ru Yandeks.Metrika
Forum: "Andere";
Aktuelles Archiv: 2017.04.30;
Herunterladen: [xml.tar.bz2];

Nach unten

Kann das Client-Zertifikat auf dem Server identifiziert werden? Finden Sie ähnliche Zweige


sniknik ©   (2016-04-19 13:23) [0]

Eher ist es ein bisschen falsch, der Apache bestimmt, die Anfragen gehen ... d.h. Es ist möglich, aber ich brauche einen Nachweis (ein Protokoll, wenn diese Daten dort geschrieben werden können).

Im Allgemeinen ist die Situation: Jeder Agent arbeitet unter seinem eigenen Zertifikat, das er von uns anfordert, lokal generiert / speichert er den privaten Schlüssel auf dem Server, seine "Hälften" werden natürlich gesendet. Nun, jetzt hat einer von ihnen "geschossen", als ob "diese Anfragen nicht von mir stammen, habe ich nicht." Es spielt keine Rolle, dass er es in den lokalen Protokollen des Programms hat, es spielt keine Rolle, dass eine "Verschlüsselung / Entschlüsselung" durch das Zertifikatspaar eines anderen nicht möglich ist.
NDA

Selbst ist nicht Odmin, und nicht ohne Gefahr, aber ... von ihnen, meiner Meinung nach, mehr Probleme als gut.
Kann auf dem Server / Apache im Allgemeinen konfiguriert werden, unter welcher ID / Signatur das Zertifikat gespeichert werden soll, unter dem die Anforderung gestellt wurde?



KilkennyCat ©   (2016-04-19 13:56) [1]

Wenn mod_ssl verwendet wird, gibt es ein benutzerdefiniertes Protokoll. Sie können eine Reihe von SSL_CLIENT_ * schreiben.



KilkennyCat ©   (2016-04-19 13:58) [2]

Leider kann ich mich nicht erinnern, wie.
siehe hier: https://httpd.apache.org/docs/2.4/mod/mod_ssl.html - "Umgebungsvariablen" und "benutzerdefiniertes Protokollformat"



DVM ©   (2016-04-19 14:02) [3]


> sniknik © (19.04.16 13: 23)


> "Zeigen Sie mir auf dem Server, dass es sich um ein Zertifikat handelt
> die Anfrage war "...

Und was will er eigentlich sehen? Logbucheintrag? Und was soll da geschrieben werden?
Dies ist im Wesentlichen eine Textdatei, in die alles geschrieben werden kann. Die Tatsache der Verbindung ist jedoch ein Beweis, da es kein Zertifikat und keine Verbindung gibt.



KilkennyCat ©   (2016-04-19 14:04) [4]


> DVM © (19.04.16 14: 02) [3]
> Aber die Tatsache der verbindungssicheren, weil es kein Zertifikat gibt,
> keine Verbindung.

wirklich? Es schien mir, dass die Verbindung sein wird, aber nicht sicher sein wird. Zumindest habe ich kürzlich das Fehlen von Zertifikaten umgangen.



sniknik ©   (2016-04-19 14:14) [5]

> Und was will er eigentlich sehen? Logbucheintrag? Und was soll da geschrieben werden?
Welche Art von digitaler Signatur des Kunden, durch die sein Zertifikat eindeutig identifiziert wird (und nicht zum Beispiel ein von unserem Administrator an seinen Freund ausgestelltes Double ...). Xs. wie er es sich vorstellt (denn selbst dort wird das Duplikat dort nicht funktionieren, die Verbindung wird nicht funktionieren, aber dann ... gibt es noch eine Kette von Managern / Kennungen / Einstellungen, auf die der Administrator bereits keinen Zugriff hat ... sollte es nicht sein).

> Aber die Tatsache der verbindungssicheren, weil es kein Zertifikat gibt, keine Verbindung.
Ja, irgendwie kann ich diesen einfachsten Gedanken nicht zu unserer eigenen Sicherheit "übermitteln" (diese Arschlöcher haben aus irgendeinem Grund entschieden, dass dies kein Beweis ist ... Unter dem Druck eines Agenten scheinen sie schlechter als ich in dem Thema "zu schweben", obwohl sie es sind muss wissen).



sniknik ©   (2016-04-19 14:17) [6]

> Die Verbindung wird zwar hergestellt, ist jedoch nicht sicher.
Nein, dazu muss der Client / Server eine ungeschützte Verarbeitung erlauben / haben. Aber wenn der Server akzeptiert und versucht, nur das verschlüsselte zu entschlüsseln, wird das Paket entschlüsselt. Was passiert, wenn Sie versuchen, es ohne Fehler zu entschlüsseln? Bitte schön.



sniknik ©   (2016-04-19 14:24) [7]

> schau hier:
An Administratoren gesendet ... Mal sehen, ob es hilft.



KilkennyCat ©   (2016-04-19 14:26) [8]


> sniknik © (19.04.16 14: 17) [6]

in diesem Fall sympathisieren. In ihrer Auslegung zeigt sich, dass Zertifikate in der Regel bedeutungslos sind. logge alles in einer reihe, lass es später auseinander nehmen.



DVM ©   (2016-04-19 14:52) [9]


> sniknik © (19.04.16 14: 14) [5]


> Ja, irgendwie kann ich diesen einfachsten Gedanken nicht "vermitteln"
> zu unserem Safe

In einem Projekt habe ich auch Client-Zertifikate verwendet (obwohl sie auf dem JaCarta-Schlüssel aufgezeichnet wurden), und daher hat der Client dort seine Aktionen (Protokolle und Dokumentenerstellung) mit seinem Schlüssel signiert. Der GOST-Algorithmus, der im Schlüssel integrierte Kryptografieanbieter, ist zertifiziert. Ausreden, dass ich nicht ich bin und mein Pferd nicht akzeptiert wurde, gibt es eine Unterschrift - ja, Sie können nur mit einem physischen Schlüssel unterschreiben.



sniknik ©   (2016-04-19 14:54) [10]

> in ihrer auslegung zeigt sich, dass zertifikate in der regel bedeutungslos sind.
Nun ja, aber die Unterschrift, die von demselben "entscheidet" Typenzertifikat gemacht wird. Unsinn.

> alles protokollieren
Ja, praktisch ist es, und in den Protokollen können Sie das "Hacken" des Netzwerks sehen (in Anführungszeichen, da dies für unsere Software eine reguläre Eingabe ist, mit einem normalen registrierten Login / Passwort, das heißt, es kann kein Hacken sein, vielleicht bleibt der Kassierer ohne Anmeldung und wer Ich habe es benutzt). Das Einzige, was als Problem angesehen werden kann, ist, dass die Zahlungen den Protokollen zufolge unter dem Remotedesktop erfolgen ... ABER !!! Sie alle arbeiten dort so, der lokale Administrator hielt es für korrekter und stellte die Berechtigungen ein (standardmäßig ist RDP verboten).



sniknik ©   (2016-04-19 14:58) [11]

> GOST-Algorithmus, der im Schlüssel integrierte Kryptografieanbieter ist zertifiziert
Wir haben es "nach Belieben", der Kunde entscheidet, welches Zertifikat ihm am Herzen liegt. In diesem Fall handelt es sich um RRS X.509.

> Sie können nur mit einem physischen Schlüssel signieren.
Er steht da, Agenten mögen das nicht. Selbst wenn die Datei auf ein USB-Flash-Laufwerk geschrieben werden kann, ist dies nach Logik der Fall. Aber sie denken auch nicht gern.



дапофик ©   (2016-04-19 15:08) [12]

Client-Browser oder voll?

wenn die zweite, dann war es nicht notwendig, den Kanal mit Sésel zu schließen,
Verschlüsseln / Signieren und Senden von Anwendungsdaten über einen beliebigen Kanal.



дапофик ©   (2016-04-19 15:11) [13]

und wenn alles bespeka auf dem Kanal war, dann ist Borjomi zu spät, um zu trinken.

Nehmen wir an, Sie finden in den Apache-Protokollen, dass eine solche und eine solche Anfrage, ein solches und ein solches Datum mit einem solchen IP-Typ mit einem Zertifikat mit einer solchen Seriennummer und einem solchen Fingerabdruck signiert wurde, und warum?

Das ist also ein Protokoll und du hast es mit deinen Händen gezeichnet.
hier zeigst du mir meine Bitte und meine e-Signatur dazu.

Ich spreche mit Ihrem aufgeregten Kunden



DayGaykin ©   (2016-04-19 15:23) [14]

Pakete, die vom Client stammen, werden nicht mit dem privaten Schlüssel des Clients verschlüsselt, sondern mit dem Sitzungsschlüssel. Dieser Sitzungsschlüssel wird zu Beginn der SSL-Sitzung mit dem Diffie-Hellman-Protokoll generiert und unter anderem mit privaten Schlüsseln bestätigt.

Selbst wenn Sie verschlüsselte Daten aufschreiben, müssen Sie daher bestätigen, dass es dieser Client war, der sie nicht verschlüsselt hat. (oder Sie müssen den Sitzungsschlüssel und seine Signatur speichern).

Daher müssen Sie die Anforderung selbst mit einem Client-Zertifikat signieren und eine Signatur zusammen mit der Anforderung senden. Zeichnen Sie auf dem Server alle Anforderungen und Signaturen auf.

Dies ist nicht schwer zu implementieren, wenn der Client Ihre native Anwendung ist.

HTML + JS kann meines Wissens keine Formulare signieren. Aber das ist IMHO, weil Nie zuvor war ich so eine Aufgabe. Es gibt einige https://www.w3.org/TR/WebCryptoAPI/ (Unterstützung: http://caniuse.com/#search=Web%20Cryptography). Prüfen Sie, ob Sie damit ein Client-Zertifikat signieren können.



sniknik ©   (2016-04-19 15:25) [15]

> siehe hier: https://httpd.apache.org/docs/2.4/mod/mod_ssl.html - "Umgebungsvariablen" und "benutzerdefiniertes Protokollformat"
SSL_CLIENT_CERT Zeichenfolge PEM-codiertes Clientzertifikat
Ist es möglich, das gesamte Client-Zertifikat auf dem Server abzurufen? Oder habe ich nicht verstanden, was?
Aber im Allgemeinen, wenn ja, dann kann nicht mehr gewünscht werden ...

> Es war nicht notwendig, den Kanal mit Sesel zu schließen.
Es ist sinnlos zu diskutieren, was passieren würde, wenn und wie es geht ... wie es auch geht, die Decke ist nicht eingeflogen, es wurde wie befohlen gemacht.



sniknik ©   (2016-04-19 15:29) [16]

> Es ist nicht schwer zu implementieren, wenn der Client Ihre native Anwendung ist.
Mein Client, kein Server. Und selbst wenn ich auf dem Client eine Signatur hinzufüge (obwohl dies meiner Meinung nach überflüssig ist), muss auf dem Server niemand überprüft / geschrieben werden ... und die Anforderung mit einigen zusätzlichen Parametern wird nicht übergeben, da sie gemäß dem regulären Ausdruck für die Überprüfung abgeschnitten wird.



sniknik ©   (2016-04-19 15:32) [17]

> müssen entweder den Sitzungsschlüssel und seine Signatur speichern
Ist das ein Standard auf dem Server? Ist es möglich, vor dem Bestimmen des tatsächlichen Zertifikats / Client-Schlüssels ein „Aufdrehen“ durchzuführen?



дапофик ©   (2016-04-19 15:33) [18]

Mit Protokollen schicken Sie kompetente Anwälte irgendwohin

Um die Handlung des Kunden zu beweisen, benötigen Sie einen Blob seiner Anfrage und eine Blob-E-Signatur dieser Anfrage.
na ja, oder wenn sich die e-signatur dort nicht löst, dann nur ein signierter request blob.



DVM ©   (2016-04-19 15:39) [19]


> sniknik © (19.04.16 14: 58) [11]


> Obwohl auch die Datei auf ein USB-Flash-Laufwerk geschrieben werden kann und wird
> die gleiche Logik.

Nein, nicht dasselbe. Der private Schlüssel darf nicht vom Datenträger entfernbar sein und darf ihn nicht verlassen. Daher müssen die Datenträger ihn generieren und damit arbeiten. Ein Flash-Laufwerk kann dies nicht.



sniknik ©   (2016-04-19 15:40) [20]

B .... b, die ganze Frage ist geschlossen. Sie haben nicht nur ein Client-Zertifikat, sie verwenden es auch ...
$ ssl = openssl_x509_parse ($ _ SERVER ['SSL_CLIENT_CERT']);
Und nachdem sie die Agentenkennung herausgezogen haben ... d.h. Es gibt eine doppelte Garantie, verbunden, ausgepackt, und sogar der Ausweis kam zusammen ... Ich hätte getötet, "wir haben nicht gedacht." Es gibt keine Worte. Und theoretisch beschäftigen sie sich damit, sie erhalten Geld.



sniknik ©   (2016-04-19 15:42) [21]

> Der private Schlüssel darf nicht vom Datenträger entfernt werden und darf ihn nicht verlassen
Sie haben gerade keine geschützten Flash-Laufwerke gesehen. Ich im Prinzip auch;), aber sie haben mich überzeugt, dass die "Garantie" Sie nicht ohne Passwort lesen können.



DVM ©   (2016-04-19 15:43) [22]


> DayGaykin © (19.04.16 15: 23) [14]


> HTML + JS kann meines Wissens keine Formulare signieren.

Auf dem Computer des Benutzers wird ein lokaler Webdienst erstellt (mit allen Zertifikaten und Berechtigungen), der alles mit einem Schlüssel signieren kann. Signaturanforderungen von JS auf der Seite der Site werden an diesen lokalen Server gesendet und erhalten die Signatur zurück. Der Installateur eines solchen Dienstes kann vollautomatisch erfolgen.



DVM ©   (2016-04-19 15:46) [23]


> sniknik © (19.04.16 15: 42) [21]


> Sie haben gerade keine geschützten Flash-Laufwerke gesehen.

Nein, es ist immer noch anders. Ein solches Flash-Laufwerk muss in der Lage sein, Daten zu signieren, einen Schlüssel, den noch niemand gesehen hat und der vom Flash-Laufwerk selbst generiert wird, wenn es dieselbe Anforderung für ein Benutzerzertifikat bildet.



sniknik ©   (2016-04-19 15:46) [24]

> Kompetente Anwälte schicken Ihnen irgendwo Protokolle für einen Spaziergang
Meine Aufgabe ist es nicht, vor Gericht zu erscheinen, sondern otmazyvatsya von auferlegter sinnloser Arbeit ... die kommt, wenn einige unzulängliche "Fachkräfte" nicht eingesetzt werden.
Alles weitere geht mich nichts an.



дапофик ©   (2016-04-19 15:49) [25]

> Der private Schlüssel darf nicht vom Datenträger entfernt werden und darf ihn nicht verlassen

Diese These ist vor hundert Jahren veraltet.

Auf dem Flash-Laufwerk befindet sich nicht der Schlüssel selbst, sondern der Schlüsselbehälter.
Ja, sogar auf einer Diskette.

und im Benutzerbereich der Bibliothek kann es nicht aus dem Container entfernt werden.

und die These setzt ein Gleichheitszeichen zwischen dem Träger und dem Behälter



sniknik ©   (2016-04-19 15:49) [26]

> Nein, es ist immer noch anders.
Naja, wenn du "gräbst", dann ja noch einen. Ich habe mit Aladin gearbeitet, etwas Ähnliches hatten sie. Und in Aussehen / Aktion das gleiche, bis sie das Passwort zusammen gestohlen haben, gibt es keinen Zugang ohne ein physikalisches Medium.



DVM ©   (2016-04-19 15:55) [27]


> dapofik © (19.04.16 15: 49) [25]


> und im Benutzerbereich der Bibliothek kann es nicht aus dem Container entfernt werden.

Was einige geschafft haben, werden andere extrahieren können. Also ist nichts veraltet.
Außerdem existierte der Schlüssel, bevor er in den Container geschrieben wurde, einige Zeit getrennt davon (obwohl RAM). das ist an sich unzuverlässig.



DayGaykin ©   (2016-04-19 15:59) [28]


> $ ssl = openssl_x509_parse ($ _ SERVER ['SSL_CLIENT_CERT']);
> Und nachdem Sie die Agentenkennung herausgezogen haben ... d.h.
> Es gibt eine doppelte Garantie, verbunden, ausgepackt und sogar ID
> konvergiert ... Würde töten, "wir haben nicht gedacht." Es gibt keine Worte. Und sie
> theoretisch nehmen sie daran teil, sie erhalten geld.

Wie kann dies den Nachweis erbringen, dass dieser bestimmte Client die Anfrage gesendet hat?



дапофик ©   (2016-04-19 16:01) [29]

Im Allgemeinen geht es bei all dem Gerede über dumme Sicherheitskräfte um nichts.

Im Inneren versteht jeder, was der Kunde von der Anfrage verlangt hat.
außerhalb (vor Gericht) werden Sie nichts mit Protokollen beweisen.
für "sie schreiben nicht so"

und wenn das thema auftaucht, dass niemand vor gericht geht und das nicht meine aufgabe ist, dann gibt es überhaupt keine frage.
da gibt es keine Notwendigkeit, etwas zu beweisen.

und wenn nötig, sollte die Sicherheit nicht auf der Kanalsicherheit aufbauen,
aber auf Antragsdaten.



DVM ©   (2016-04-19 16:02) [30]


> DayGaykin © (19.04.16 15: 59) [28]

Soweit ich weiß, hat er zuvor mit demselben Zertifikat eine TLS-Verbindung zum Server hergestellt. Der Server vertraut nicht allen Zertifikaten. Nachdem die Verbindung hergestellt wurde, wird das SSL_CLIENT_CERT-Zertifikat des Servers in den Servervariablen gespeichert. Daher wurde die Anforderung vom Eigentümer dieses Zertifikats innerhalb der TLS-Verbindung gestellt.



дапофик ©   (2016-04-19 16:05) [31]

daher wird die Anfrage gestellt

nein

sollte nicht.



DVM ©   (2016-04-19 16:05) [32]


> dapofik © (19.04.16 16: 05) [31]

erklären



дапофик ©   (2016-04-19 16:08) [33]

Die Anfrage war letzten Montag.
und das Client-Zertifikat wurde vom Monday-Server überprüft.
und lesen Sie die Protokolle heute.
und welche Art von Server der Server am letzten Montag war und was er dort am Montag vertraute - heute weiß niemand mehr.

Dort wechselt man in der Regel die Server wie Handschuhe.
.... um ehrliche, unschuldige Kunden mit ihren gefälschten Protokollen zu wärmen.



DVM ©   (2016-04-19 16:18) [34]


> dapofik © (19.04.16 16: 08) [33]

Ich habe in [30] nicht ganz darüber gesprochen. Es ist klar, dass ein regulärer Protokolleintrag nichts beweist. Eine andere Sache ist, dass Benutzer beim Anmelden auf dem Server aufgefordert wurden, einige Daten für ihre Zertifikate zu signieren und diese Signatur in das Protokoll aufzunehmen. Dann hätte es ein weiteres Gespräch gegeben.



sniknik ©   (2016-04-19 16:18) [35]

> Wie kann damit nachgewiesen werden, dass dieser Kunde die Anfrage gesendet hat?
In der generierten Agenten-ID weiß ich nicht, wie es funktioniert (ich möchte nicht auf Details eingehen). Die Hauptsache mit dieser ID ist ALL, d. H. wenn er nicht zustimmte, dann ist schon alles so schlimm, dass die kleinen dinge mit zertifikaten nur "staub unter den füßen" sind.

ps Ich spreche nicht über Beweise vor Gericht, es scheint überhaupt nichts zu beweisen.



sniknik ©   (2016-04-19 16:25) [36]

> Alle Daten zu Ihren Zertifikaten und diese Signatur werden in das Protokoll aufgenommen. Dann hätte es ein weiteres Gespräch gegeben.
Ich habe oben geschrieben, dass es ein Client-Zertifikat gibt, das beim Parsen verwendet wird, was bedeutet, dass es geschrieben ist. Es ist eine andere Sache, dass sie bereits über das Thema verweilen, dass es "kein Beweis" ist, der Beweis ist der private Schlüssel ... obwohl ich hier sicher weiß, dass er vom Agenten generiert wird und auf keinen Fall seinen Computer verlässt ... er schrieb die Anweisung über "Actions when" Kompromittierung (Verlust) des Zertifikats / privaten Schlüssels durch den Agenten. "



DVM ©   (2016-04-19 16:34) [37]


> sniknik © (19.04.16 16: 25) [36]


> Ich habe oben geschrieben, dass es beim Parsen ein Client-Zertifikat gibt,
> gebraucht und daher geschrieben.

Nein, Sie wissen, was los ist. Das eine im Protokoll ist ein Client-Zertifikat (bei dem es sich im Allgemeinen nicht um geheime Informationen handelt), das andere sind Daten, die mit dem privaten Schlüssel des Benutzers signiert wurden (der natürlich nicht im Zertifikat enthalten ist).
Jeder kann das Zertifikat ablegen und nur der Besitzer des privaten Schlüssels kann es signieren.



sniknik ©   (2016-04-19 17:34) [38]

> Nein, Sie verstehen, was los ist
Warum ich nicht verstehe, verstehe ich. Die Frage / Behauptung betraf jedoch speziell das Zertifikat. Wenn Sie nach Logik / Bedeutung suchen würden, gäbe es genügend Client-Protokolle, in denen, wie Sie ursprünglich Anforderungen geschrieben haben, Antworten von unserem Server darauf vorhanden sind ... und wir, der Server, keinen Zugriff auf Client-Protokolle usw. haben.

> und nur der Besitzer des privaten Schlüssels konnte signieren.
Soweit ich weiß, ist dies in unserem Fall im Allgemeinen auch ein Problem, wenn Sie eine 2-Zertifikatsanforderung gestellt haben, d. H. der Client überschreibt den ersten privaten Schlüssel, d.h. Hat der zweite das Zertifikat von der ersten Anfrage erhalten, dann funktioniert dieses Paar nicht, um irgendetwas zu signieren.



DVM ©   (2016-04-19 17:40) [39]


> sniknik © (19.04.16 17: 34) [38]


> Soweit ich weiß, handelt es sich im Allgemeinen auch um ein Paar

Es ist.


> d.h. hat eine zweite, aber eine Bescheinigung von der ersten Anfrage erhalten,
> dann funktioniert dieses paar nicht zum signieren.

Wird nicht funktionieren. Das heißt, er kann offiziell unterschreiben, weil die signatur ist nur eine berechnung des hashs und seiner verschlüsselung mit dem privaten schlüssel, nur dann wird diese signatur mit dem öffentlichen schlüssel aus dem falschen zertifikat nicht entschlüsselt und somit nicht verifiziert.



Игорь Шевченко ©   (2016-04-19 21:06) [40]

Sniknik © (19.04.16 17: 34) [38]

Wenn nicht ein Geheimnis, ist das hier der Arsch, von dem du sprichst?



KilkennyCat ©   (2016-04-19 21:27) [41]

Was die Beweise vor Gericht angeht ... Sie können es wahrscheinlich beweisen. Das Konzept des "elektronischen Dokuments" wurde in der Sowjetzeit eingeführt.
Wenn Sie nur kommen und sagen: "Hallo, ich habe Ihnen ein Protokoll hierher gebracht", funktioniert es natürlich nicht.
Aber eine Kopie in der Vereinbarung zwischen dem Kunden und dem Line Office vom Typ "Die Tatsache der Transaktion ist ein Datensatz im Protokoll" - Sie können bereits mit einem Protokoll kommen und "Hallo" sagen.
Obwohl diese Lösung für die Situation, die bereits stattgefunden hat, natürlich nicht helfen wird.



дапофик ©   (2016-04-19 21:34) [42]

Verträge haben die Eigenschaft, als rechtsunwirksam anerkannt zu werden.

Sie werden kein Protokoll überprüfen.
und Sie können den aktuellen signierten Blob überprüfen



KilkennyCat ©   (2016-04-19 22:13) [43]


> dapofik © (19.04.16 21: 34) [42]
> Verträge haben die Eigenschaft, als rechtsunwirksam anerkannt zu werden.
>

nicht in allen Fällen. du kannst nicht kommen und sie für nichtig erklären



KilkennyCat ©   (2016-04-19 22:15) [44]

und in diesem Fall funktioniert es nicht: Es liegen keine Verstöße vor und beide Parteien haben vereinbart, das elektronische Protokoll als Beleg anzuerkennen.
Dies ist nicht das, was ich mir ausgedacht habe - die Rechtspraxis, in unserem Land mit elektronischen Dokumenten zu arbeiten.



дапофик ©   (2016-04-19 22:27) [45]

Ich rede.
dass "drinnen" ist allen klar.

aber.
Wenn es auf den Punkt kommt, funktionieren die Protokolle nicht.

Ein kompetenter Anwalt wird auch Ihre Protokolle und Vertragsklauseln gewinnen.

Wenn Sie also der Meinung sind, dass es ausreicht, dass "wir uns darauf geeinigt haben, einander zu glauben", werden die Protokolle und Elemente überhaupt nicht benötigt.

Es reicht aus, dem Kunden einfach zu erklären, ohne zu argumentieren, dass "bei uns alles in Ordnung ist, wir wissen, dass Sie es getan haben".



sniknik ©   (2016-04-19 22:39) [46]

> Wenn es kein Geheimnis ist, ist dies der Punkt, von dem Sie sprechen?
Qiwi, aber ich kenne den Agenten nicht, eine Art Bank.



дапофик ©   (2016-04-19 22:41) [47]

Wir haben uns zum Beispiel erst vor Gericht getroffen.

Ich (Klient): Ich habe das nicht getan
Sie: Sie haben es geschafft, wir haben ein Protokoll und wir haben uns darauf geeinigt, dem Protokoll zu vertrauen
I: Ich glaube Ihrem Protokoll, wie im Vertrag angegeben. ABER! Ich glaube nicht, dass Ihr Protokoll Ihr Protokoll ist.

Sie: aber das ist unser echtes Protokoll!
I: Verlegenheit ist wahr, das Protokoll wird von Ihren Entführern gefälscht, die Sie getäuscht haben, indem sie sich als echt ausgaben. Aber ich würde dem wahren Log glauben!

was weiter?
Ich halte mich an den Vertrag und lese den Absatz über die Zeilen des Protokolls.
Ich glaube einfach nicht, dass mir das Log echt gezeigt wird.

Sackgasse.
geh vor Gericht.

urteile mir: was ist dein beweis dafür, dass das protokoll gefälscht ist?
Ich bin Richter: Im Logbuch steht, was ich nicht getan habe. Das Protokoll ist falsch.
urteile für dich: wo ist dein authentischer log?



sniknik ©   (2016-04-19 23:00) [48]

> Es liegen keine Verstöße vor und beide Parteien haben vereinbart, das elektronische Protokoll als Beleg anzuerkennen.
Übrigens ist es keine Tatsache, ich habe keinen einzigen Vertrag gesehen (nicht mein Geschäft), und so hz. was erkennen sie ...
Das ist es, was ich bei der Anforderung eines Zertifikats "Public Key Recognition Act" formuliere, was auch immer das bedeutet (die vorherigen Sicherheitsbeauftragten, die dieses System tatsächlich erfunden haben, sagten, dass alles davon bestimmt wird, obwohl es an den Server gesendet zu werden scheint, um ein Zertifikat mit zu generieren Bindung an die Wurzel) ... nun, die Schlüsselteile werden in das Dokument eingefügt - RSAKey, Prefix, Modulus, Postfix, Exponent, und es muss von beiden Parteien signiert werden. Aber sie sollten und tun ... hz im Allgemeinen kann ich es nicht kontrollieren.

> gegenüber dem Kunden erklären, ohne zu argumentieren: "Wir haben alles richtig gemacht, wir wissen, dass Sie es getan haben."
Ein Argument in Form von Protokollen vom Client selbst, in denen die Anforderungen "ohne Argumentation" sind?

> Ein kompetenter Anwalt gewinnt Ihre Protokolle und Vertragsklauseln.
Ein kompetenter Anwalt wird alles im Allgemeinen besiegen, das Gesetz, die Logik und der gesunde Menschenverstand wurden nicht für ihn geschrieben, und lassen Sie uns dies über Anwälte beenden. Es wurde keine Berufung beim Gericht eingelegt, und dies ist unwahrscheinlich.



sniknik ©   (2016-04-19 23:05) [49]

> Was ist Ihr Beweis dafür, dass das Protokoll gefälscht ist?
Im Allgemeinen geht es nur um Protokolle. Dies ist der Punkt, an dem der Server den verschlüsselten Client mithilfe von Pair-Schlüsseln entschlüsseln musste. Dies ist der Beweis, wie oben beschrieben. Andernfalls wird das gesamte Zertifikatsystem kompromittiert, und es kann überhaupt nichts mehr als vertrauenswürdig angesehen werden.



дапофик ©   (2016-04-19 23:12) [50]

Das muss der Server entschlüsseln

Es bedeutet nichts.
und nichts davon folgt.

Kaufen Sie einfach Design.

"non-denial of authorship" - Verschlüsselung / Entschlüsselung wurde von niemandem beantwortet.



дапофик ©   (2016-04-19 23:14) [51]

Das ist es, was der Server hat, um den verschlüsselten Client, das Schlüsselpaar, zu entschlüsseln. Dies ist der Beweis.

hat den Server gestoppt, den Root-Server geändert, eine gefälschte Sitzung durchgeführt, erneut gestoppt, alles auf die Rückseite zurückgeschickt und erneut gestartet.

Geschäft, hospadi .....



дапофик ©   (2016-04-19 23:17) [52]

Es wurde keine Berufung beim Gericht eingelegt, und dies ist unwahrscheinlich.

dann sind alle fragen, wie man dort am client etwas feststellt, sinnlos.
sag einfach "bei uns stimmt alles"
Es ist dasselbe, als würde man dort einige Protokolle stöbern und gleichzeitig ein schickes Gesicht machen.



DVM ©   (2016-04-20 07:15) [53]

Übrigens praktizieren mittlerweile viele Banken die Bestätigung von Zahlungen per SMS. Das hat also auch keine Rechtskraft. Nur die Signatur ist mit einem Zertifikat gültig, das von einer zertifizierten Zertifizierungsstelle ausgestellt wurde, z. B. State Services oder Crypto.
Trotzdem klappt irgendwie alles.



sniknik ©   (2016-04-20 09:03) [54]

> etwas, das für den kunden da ist, ist bedeutungslos.
Irgendwo oben schrieb ich die Bedeutung - von sinnloser Arbeit zu otmazatsya. Es gibt ein Problem, es bedeutet, dass es gelöst werden muss, und sie bestimmen, wer es lösen wird (zumindest auf der entscheidenden Ebene der Beratung). Dies sind genau die Personen, die, wie sich herausstellt, nicht einmal die Prinzipien der Arbeit UNSERES Teils kennen, aber bereits Dutzende von wahnhaften Empfehlungen für die Neugestaltung von Client-Software gegeben haben bei denen es überhaupt keine beschwerden gibt und auch nicht sein kann Vollzeit Arbeit an der bösartigen Software, was sind die Behauptungen? Und sie beginnen zu erfinden (schnüffeln ... wie es scheint :), wie Sie eine normale Zahlung von der gleichen, aber nicht autorisierten Zahlung unterscheiden oder wie Sie sich vor einem Zertifikatdiebstahl durch den lokalen Administrator schützen, der sie vom Client angefordert und installiert hat (Empfehlungen zum Ändern der Zertifikate nach der verantwortlichen Person) Es gibt einen Administrator, aber sie verwenden sie nicht und sie werden sich davor schützen, nda) ... es wäre lächerlich, wenn es nicht die Chance gäbe, dass sie es mir nach der Implementierung vorlegen würden.

> Aber trotzdem, wie alles funktioniert.
Es ist nur irgendwie so ... es wird das Gericht erreichen und jedes Schema wird "zusammenbrechen". Übrigens ist ein Cryptopro nicht das zuverlässigste Zertifikat, da es wahrscheinlich oben liegt, aber es sind die einzigen, die irgendwie von einem Computer auf einen Computer (zum Beispiel zu Hause) übertragen werden. Vielleicht, natürlich, weil die weit verbreiteten, massiven im monetären Bereich Erfolge aufweisen, aber in der Tat hatten wir immer noch keine Probleme mit der hausgemachten Bindung an den Computer, aber die Gostovskys kopierten und nicht einmal die Admins, es gibt keinen Schutz davor, wenn Sie faul werden.
Ich weiß nicht, wie sie es kopiert haben, ich bin nur auf Konsequenzen gestoßen / auf versteinerte Tatsachen wie die Zahlung auf dem einzigen Zertifikat, das von einem Computer mit einer anderen IP ausgestellt wurde, und der Agent hat nicht eingeschränkt, was von nur einem zu akzeptieren ist.



KilkennyCat ©   (2016-04-20 09:15) [55]


> Nur eine von einem zertifizierten Zertifikat ausgestellte Unterschrift ist gültig.
> UTs, zum Beispiel State Services oder Cryptopro.

Nein. Genauer gesagt, nicht nur und nicht in allen Fällen.
Weitere Einzelheiten im Bundesgesetz von 06.04.2011 N 63-ФЗ (in der durch 30.12.2015 geänderten Fassung) "Über die elektronische Signatur"
aber im Allgemeinen: Es gibt das Konzept einer einfachen elektronischen Signatur: Eine einfache elektronische Signatur ist eine elektronische Signatur, die durch die Verwendung von Codes, Passwörtern oder anderen Mitteln die Tatsache bestätigt, dass eine bestimmte Person eine elektronische Signatur erstellt.
Außerdem: Eine elektronische Signatur und ein von ihr unterzeichnetes elektronisches Dokument können nicht als nichtig angesehen werden, nur weil das Zertifikat des Schlüssels zur Überprüfung der elektronischen Signatur in Übereinstimmung mit ausländischem Recht ausgestellt wurde.



дапофик ©   (2016-04-20 09:18) [56]

Trotzdem klappt irgendwie alles.

Dies ist ein Fall mit Physik und Physik für Physiker, und dies ist ein Fall, in dem jeder objektiv "braucht".

Einerseits brauchen Physiker das Dbo, und das ist wahr.
Auf der anderen Seite möchte sich niemand mit dem Desktop-Client für Physiker beschäftigen, auch nicht mit sich selbst. Das heißt, sie haben dort einen Browser-Client.
Auf der dritten Seite gibt es keine normale Kryptolösung für die Anwendungsebene in Browsern.

entweder auf zB + capicom + win beschränkt sein oder Java-Applets belasten

aber da "notwendig" ist dann alles auf einen sicheren sms-kanal "kami" und andere krücken beschränkt.

Rechtsanwälte haben natürlich auch SMS in Desktop-Clients, aber es gibt eine zusätzliche Funktion, die das Problem der Authentifizierung nicht löst, sondern nur das Leben von Angreifern verkompliziert.



sniknik ©   (2016-04-20 10:28) [57]

Vom Moderator gelöscht
Hinweis: Ausdrücke wählen



sniknik ©   (2016-04-20 10:33) [58]

> weiß nicht was und wie es funktioniert
Übrigens scheinen sie so zu denken, wie Sie es getan haben ... IMHO, durch indirekte Angaben (Client-Protokolle wurden erst nach 2-Wochen angefordert, ich habe sie in einer Woche gefragt ... direkt nachdem sie sich mit dem Problem verbunden hatten). Meiner Meinung nach. Obwohl dies bereits ein offtopic ist.



DVM ©   (2016-04-20 13:41) [59]


> sniknik © (20.04.16 09: 03) [54]


> Das cryptopro ist übrigens auch dort nicht das zuverlässigste Zertifikat
> wahrscheinlich dofiga an der spitze, aber ihre einzigen irgendwie übertragen
> von Computer zu Computer (z. B. zu Hause). Vielleicht natürlich weil
> weit verbreitet, massiv im monetären Bereich, und es gibt Entwicklungen,
> Tatsächlich hatten wir aber immer noch keine Probleme mit selbst erstelltem Binding
> auf den Computer, aber die Gostovskie kopiert und nicht einmal Admins, aus
> Dies ist im Allgemeinen kein Schutz, wenn Sie "faul" werden.

Nun, was das Kopieren des Zertifikats betrifft (genauer gesagt, der private Schlüssel, das Zertifikat selbst ist kein Geheimnis), hängt alles davon ab, wo und wie dieser private Schlüssel gebildet wurde, und es wurde die Anforderung gestellt, ein Zertifikat für diesen Schlüssel auszustellen.
Wenn Sie gerade eine Art OpenSSL verwendet haben und der private Schlüssel danach auf der Festplatte liegt, ist das Ziehen oder Verschieben kein Problem.
Wenn der private Schlüssel sicher in einem vom Betriebssystem gesperrten Containerzugriff verborgen ist und mit diesem Schlüssel selbst Kryptokonvertierungen durchführt, kann es zu Schwierigkeiten bei der Übertragung kommen. Dies ist aber auch lösbar, wenn auch unpraktisch. Am bequemsten sind externe IMHO-Medien mit einem nicht entfernbaren Schlüssel und einem integrierten Kryptografieanbieter wie JaCarta.



DVM ©   (2016-04-20 13:45) [60]


> dapofik © (20.04.16 09: 18) [56]


> normale Kryptolösungen von Drittanbietern für die Anwendung
> In Browsern gibt es keine Ebene.

Da ist etwas. Hier ist ein Beispiel: http://www.aladdin-rd.ru/solutions/jcwebclient/
Keine Java-Applets oder -Plugins (für alle Browser ist NPAPI geschlossen)
Es funktioniert ungefähr so, wie ich es in [22] beschrieben habe. Das heißt, auf dem Computer des Benutzers zusätzlich. Software.
Natürlich wäre es für alle besser, wenn die Browserhersteller eine normale API für solche Dinge erstellen würden.



дапофик ©   (2016-04-20 14:19) [61]

Ja, das ist Müll.
läuft unter Windows, obwohl es keine Hindernisse gibt, aber sie taten nur für Windows
Für die Installation benötigen Sie noch Rechte, aber ich möchte dies tun, indem ich in ein Internetcafé gehe.

Ich hatte vor Jahren genau das gleiche Bike 9.



дапофик ©   (2016-04-20 14:38) [62]

und diese Sache denkt auch, dass, wenn der Proxy nur 127.0.0.1 bindet, es wie in einem Haus ist.

und hier arbeitet der legitime interaktive Benutzer mit ihm zusammen, plus der Benutzer im RDP und plus der Benutzer im VNC.
und jeder generiert jedes seiner Dokumente und das wird eine elektronische Signatur desjenigen haben, der das Flash-Laufwerk geklebt hat.



DVM ©   (2016-04-20 15:04) [63]


> dapofik © (20.04.16 14: 38) [62]

Es wird keine Probleme geben, Sie müssen immer noch den Geräte-PIN-Code eingeben. Es können mehrere Geräte stecken bleiben, Sie können Ihre eigenen auswählen.



sniknik ©   (2016-04-20 15:31) [64]

> Wenn der private Schlüssel sicher in einem Container versteckt ist, ...
Hier ist diese Option: Wie kann ich ein Cryptopro in eine Datei auf der Festplatte einfügen, ich weiß nicht einmal wie und es wird praktisch keine Garantie übernommen?

> Dies ist aber auch lösbar, wenn auch unpraktisch.
Interessant, wie? Es gab Fälle, in denen das Zertifikat in der Windows-Registrierung installiert wurde (in diesem Fall habe ich die Adresse der Registrierung CURRENT_USER \ MY \ oder LOCAL_MACHINE \ MY \ angegeben, wenn ich arbeite). Es gibt keine Probleme mit der "Eisen" -Version für sich ... obwohl es SEHR wenige dieser Optionen gibt, ist dies vielleicht der Grund. Um das "Flash-Laufwerk" zu löschen, insbesondere wenn sie in Ihrer Zuständigkeit sind, bestellen Sie, IMHO ist auch kein Problem. Immerhin funktioniert nicht eine Kassiererin, aber ... es gibt einige, sie haben 400-Punkte, die Bestellung von 410-Schlüsseln mit zu viel für eine "Ehe" ist voila.



sniknik ©   (2016-04-20 15:34) [65]

> oder wo er legt es in diesem Fall
Dort wird beim Generieren die Funktion des Cryptopro selbst aufgerufen (es ist ein Cryptopro), und es wird sogar eine Warnung angezeigt - verwenden Sie den Windows-Assistenten nicht während der Installation, da Der Schlüssel wird nicht an den Container gebunden, und das Zertifikat ist infolgedessen nicht funktionsfähig.



DVM ©   (2016-04-20 15:50) [66]


> sniknik © (20.04.16 15: 31) [64]


> Löschen Sie das "Flash-Laufwerk", insbesondere wenn es sich in Ihrer Zuständigkeit befindet
> Sie bestellen, IMHO ist auch kein Problem. Immerhin funktioniert keiner
> Kassierer, aber ... nun, es gibt einige, sie haben 400-Punkte, um
> 410-Schlüssel mit zu viel für "Ehe" - voila.

Nun, es sind nicht nur Flash-Laufwerke, Sie kopieren keine Informationen von einem zum anderen.
Bei einer ernsthaften Vorgehensweise bei der Ausstellung von Zertifikaten wird die Option, N Zertifikate in Reserve zu bestellen, nicht erweitert, da:

1) Die Zertifikatsanforderung wird vom Hardwaregerät generiert und an die Zertifizierungsstelle übertragen.
2) CA stellt solche Zertifikate je nach Antrag, Pass usw. aus. Das heißt, Sie können sie an niemanden weitergeben und 5-Teile in Reserve abgeben.
3) Das Zertifikat wird nur auf dem Gerät abgelegt, das die Anforderung generiert hat. Andernfalls ist es sinnlos (obwohl dies möglich ist), das Paar aus privatem Schlüssel und Zertifikat wird signiert und der private Schlüssel befindet sich auf dem Gerät und kann von dort nicht gelesen und kopiert werden.
4) Wenn ein Flash-Laufwerk verloren geht / gestohlen wird, muss sofort eine Anfrage an die Zertifizierungsstelle gesendet werden, um das Zertifikat zu widerrufen. Bei seriöser Software sollte überprüft werden, ob das Zertifikat, das sie versuchten zu widerrufen, widerrufen wurde. Das verlorene Zertifikat wird mit einem neuen privaten Schlüssel im neuen Gerät an 1 zurückgesendet.



DVM ©   (2016-04-20 15:54) [67]


> sniknik © (20.04.16 15: 31) [64]


Zitiert1 >> Das ist aber auch lösbar, wenn auch unpraktisch.
> Ich frage mich, wie? Fälle waren bei der Installation eines Zertifikats in Windows
> Registrierung (oder wo er es in diesem Fall hinstellt, bin ich auf der Arbeit
> Ich gebe die Adresse der Registry CURRENT_USER \ MY \ oder LOCAL_MACHINE \ MY \ an.
>

Wie ich oben schrieb, haben es einige geschafft, zu setzen. andere werden es bekommen können. Alle Informationen befinden sich auf der Festplatte, die jederzeit durch Booten von einem anderen System oder von einer Live-CD / einem Flash-Laufwerk gelesen werden kann. Der Verschlüsselungsschlüssel liegt dort. Das einzige, was ist, wenn der Container kennwortgeschützt ist, müssen Sie das Kennwort kennen, um den privaten Schlüssel von dort zu erhalten, aber kennwortgeschützte Container werden normalerweise für den Export von Zertifikaten mit dem privaten Schlüssel erstellt, im alltäglichen Gebrauch sind sie nicht kennwortgeschützt.



дапофик ©   (2016-04-20 16:21) [68]

weil Der Schlüssel wird nicht an den Container gebunden, und das Zertifikat ist infolgedessen nicht funktionsfähig.

Sie können ein abstraktes Zertifikat nicht einfach einem Container zuordnen.
in zwei schritten erledigt.
Zuerst importieren wir das Zertifikat in einen bestimmten Zertifikatspeicher (Datei, Registrierung, LDAP usw.).
dann bekommen wir von dort seinen Zusammenhang.
und danach binden wir den Container des privaten Schlüssels.

Das Binden selbst funktioniert nicht, wenn das Zertifikat selbst beispielsweise in Form einer Datei vorliegt.



sniknik ©   (2016-04-20 16:25) [69]

> Mit ernstem Ansatz
Ich sehe in dem, was geschrieben steht, nichts besonders Ernstes, was es mir ermöglichen würde, Verluste zu vermeiden, wenn ich ein Zertifikat / Gast / RSA / Eisen / Hz stehle. Dass die Zahlungen darauf aufhören, beim ersten Rechtsmittel, wie Sie feststellen werden, ist dies ein oder zwei Stunden. Es passiert länger, sogar Monate, wenn jemand kleine Verkabelungen macht, in der Hoffnung, dass er es nicht merkt und große Büros es nicht merken. Aber das ist selten und normalerweise werden sie von innen gefangen. Bei externen Hacks wird versucht, das Geld des Agenten so schnell wie möglich zu überweisen und abzuheben, andernfalls werden sie durch Stornierung zurückerstattet.

Was hilft einer externen Zertifizierungsstelle? Oder geplante Aktionen, aber bis Sie das Zentrum mit dem Agenten kontaktieren, bleibt kein Geld mehr übrig und dies endet natürlich ... (Geld wird normalerweise für einen Werktag + - "von Kopfgeld" aufbewahrt). Nur übermäßige Hämorrhoiden.



DVM ©   (2016-04-20 16:32) [70]


> sniknik © (20.04.16 16: 25) [69]


> Ich sehe im Geschriebenen nichts besonders Ernstes

Es beschreibt die Standardprozedur für die Arbeit mit Zertifikaten. Die Hauptsache ist Genauigkeit. Und für Betrüger, die Hardwareschlüssel verlieren, wird eine Zwei-Faktor-Autorisierung eingeführt. Zusätzlich zum Hardwareschlüssel mit dem Zertifikat wird ein paar weitere Anmeldedaten / Kennwörter hinzugefügt, die an den öffentlichen Schlüssel des Zertifikats gebunden sind. Das heißt, sie werden nicht sofort so schnell Geld stehlen. Und dann wird das Zertifikat gesperrt.



sniknik ©   (2016-04-20 17:12) [71]

> Und dann wird das Zertifikat gesperrt.
Wir selbst sperren unsere Zertifikate so schnell wie möglich, und "Gouging" sind unsere Agenten. Alles, was Sie geschrieben haben, mag gut sein, aber es wird das Problem nicht lösen. Im Allgemeinen.

Zurück zu dem Fall, aufgrund dessen das Thema angezeigt wurde - Sie arbeiten an einer legal installierten Software mit einem Zertifikat, das "sorgfältig" für Sie ausgestellt wurde, einem Hardwareschlüssel (auch wenn es sich um einen Heap handelt) auf einem dedizierten RDP-Server (hier ist die "Hintertür" des Administrators) / es scheint, dass Sie Ihre Arbeit schützen sollten).
Alles scheint in Ordnung zu sein, aber der Administrator hat seinen eigenen Kanal für "externes RDP" (na ja, warum sollte er jeden Tag zur Arbeit gehen, kann er alles von zu Hause aus lösen).
Nun, eines Tages betritt der Administrator diesen externen Kanal nicht von einem anderen Computer aus (das können Sie den Programmprotokollen entnehmen), stellt eine Verbindung zu Ihrer Sitzung her und überprüft das dort eingegebene Login / Passwort ... startet dasselbe Programm (von dort aus) ! Die Client-Protokolle des Angreifers wurden direkt in der Hauptinstallation gefunden!), Ihr Passwort gibt Ihr Login im Allgemeinen genauso ein wie Sie, zeigt jedoch Ihre Daten an.
Wie schützen Sie sich davor? ("Eisen" -Zertifikat? Ja, Sie haben es selbst eingefügt! Sie arbeiten)
Wie wird alles geschrieben und generell werden alle Aktionen, die zumindest irgendwie stören könnten (nur auf das lokale Netzwerk beschränkt, RDP nicht aktivieren, keine externen Schnittstellen einbeziehen, Einschränkungen im Büro konfigurieren), vom selben Administrator "liebevoll" abgeschaltet und / oder oder setze * (all), weil er fühlt sich unwohl und müsste auf jeden Fall zur Arbeit gehen.



DVM ©   (2016-04-20 17:40) [72]


> Es sieht so aus, als hätten Sie bei der Einladung das Login / Passwort eingegeben ... beginnt
> dasselbe Programm (von dort! wurden Client-Protokolle des Angreifers gefunden
> direkt in der Hauptinstallation!), geben Sie Ihr Login-Passwort ein,
> macht im Allgemeinen dasselbe wie Sie, gibt jedoch Ihre Daten an.
>
> Wie schützen Sie sich davor? (Zertifikat "Eisen"? Ja
> Sie haben es selbst eingefügt! du arbeitest

Denken Sie, dass Sie Situationen finden können, an die andere nicht gedacht haben? :)

Habe ich schon erklärt. Um auf den Schlüssel zuzugreifen, müssen Sie einen PIN-Code eingeben.
Für besonders paranoide Menschen oder für die Arbeit in einer völlig feindlichen Umgebung gibt es spezielle Tastaturen, deren Eingaben nicht einfach so abgefangen werden: http://www.aladdin-rd.ru/catalog/antifraud/
Um mit einer bestimmten Anwendung arbeiten zu können, muss sie durch Eingabe eines PIN-Codes an einen Schlüssel gebunden sein. Der Administrator kann Ihre Eingaben weder sehen noch abfangen.
Sie können jedes Mal eine PIN anfordern, bevor Sie ein Dokument signieren.



sniknik ©   (2016-04-20 18:20) [73]

> Sie können sich solche Situationen ausdenken
Ich habe mir das nicht ausgedacht, genau das ist hier passiert. Ich habe die Realität nur mit einem eisernen Schlüssel "verschärft", aber ohne meine Tastatur habe ich nicht daran gedacht.

> Es sollte durch Eingabe eines PIN-Codes an den Schlüssel gebunden werden.
Dies kompliziert das Schema nur ein wenig, Sie müssen lediglich keine neue Anwendung starten, sondern eine Verbindung herstellen, und hoffen, dass die Kassiererin zum Beispiel beim Abendessen ist.

Obwohl ich es mir schon ausgedacht habe, hatten wir das noch nie.

Und es wird nicht wahrscheinlich sein, weil Diese Option schützt die Anwendung des Clients und in unserem Land wird der Server / Dienst häufiger, insbesondere bei Banken, zertifiziert (Vorverarbeitung), und die Clients verwalten mit einer einfachen Windows-Authentifizierung (es gibt ein Zertifikat zwischen dem Client und dem Dienst, jedoch nur für die Kanalverschlüsselung).
Trotz der Tatsache, dass sie auf einen Service „drängen“, deren Kunden aber um ein Vielfaches mehr sind ... wird es nicht.



sniknik ©   (2016-04-20 18:21) [74]

> Sie können jedes Mal vor dem Signieren eines Dokuments nach einer PIN fragen.
Nein, es ist nur für den persönlichen Gebrauch ... nicht in den Büros. IMHO.



Seiten: 1 2 ganze Branche

Forum: "Andere";
Aktuelles Archiv: 2017.04.30;
Herunterladen: [xml.tar.bz2];

nach oben









Speicher: 0.95 MB
Zeit: 0.07 c
1-1351075691
mfender
2012-10-24 14:48
2017.04.30
TListItem und wie man dorthin kommt


15-1461015004
Jury
2016-04-19 00:30
2017.04.30
Alles Gute zum Geburtstag ! 19 April 2016 Dienstag


15-1441114200
Igor Shevchenko
2015-09-01 16:30
2017.04.30
RAD Studio 10 Seattle veröffentlicht


15-1461061417
Sniknik
2016-04-19 13:23
2017.04.30
Kann das Client-Zertifikat auf dem Server identifiziert werden?


15-1461212286
Superbot
2016-04-21 07:18
2017.04.30
Ich möchte als Programmierer arbeiten





Afrikanisch Albanien Arabisch Armenisch Aserbaidschanisch Baskisch Weißrusse Bulgarian katalanisch Chinesisch (vereinfacht) Chinesische Tradition) kroatisch Tschechisch Dänisch Dutch Englisch estnisch Philippinisch Finnish Französisch
Galicisch Georgisch Deutsch Griechisch haitian Creole Hebräisch Hindi ungarisch isländisch Indonesian irisch Italian Japanisch Koreanisch lettisch litauisch Makedonisch Malay Maltesisch Norwegian
persisch Polnisch Portugiesisch Rumänisch Russisch serbisch Slovakisch Slowenisch Spanisch Suaheli Swedish Thai Türkisch Ukrainisch Urdu Vietnamesisch Walisisch Jiddisch Bengalisch bosnisch
cebuano Esperanto Gujarati Hausa Hmong igbo Javanisch kannada khmer Laotisch Lateinisch Maorisch Marathi Mongolisch nepali Pandschabi Somalisch Tamilisch Telugu Yoruba
Zulu
Английский Französisch Deutsch Italienisch Португальский Russisch Spanisch