News

Keyp und inWebo beginnen Partnerschaft im Bereich sichere dezentrale digitale Identitäten

Posted by | News | No Comments

Keyp

München & Paris, 1. Juni 2018 – inWebo ist stolz den Start einer Partnerschaft mit Keyp, dem Anbieter einer unabhängigen und dezentralen Infrastruktur für digitale Identitäten, zu verkünden. Das für den Cyber Security Start-up of the year nominierte Unternehmen mit Sitz in München, ist eines der ersten, die ein auf sichere digitale Identitäten beruhendes und ausgerichtetes Ökosystem entwickelt hat und somit Technologieanbieter (Authentifizierung, Legitimationsprüfung) mit Unternehmen, die von der Nutzung profitieren, wie Banken, Automobilhersteller und andere Dienstleister, verbindet. Als Lösung können sämtliche Identitätsmerkmale wie E-Mail-Adressen, Bankverbindungen, persönliche Daten, Ausweisdokumente, Visa, Führerscheine und Kundenkarten verifiziert und authentifiziert werden.
Die Keyp Identity Platform-as-a-Service basiert auf strengen Anforderungen in Bezug auf Sicherheit und Datenschutz, zielt aber auch darauf ab eine sehr komfortable Benutzererfahrung an jedem Berührungspunkt vom On-Boarding bis zur Authentifizierung zu gewährleisten.

inWebo war einer der ersten Partner, die der von Keyp geleiteten Initiative beitraten und diese mit ihren fortgeschrittenen Fähigkeiten und Erfahrungen in den Bereichen Mobile MFA (Multi-Faktor-Authentifizierung) und Lokale Zugansrechte einbrachten.

Lesen Sie die komplette Pressemitteilung hier.

DSGVO bei inWebo

Posted by | News | No Comments

Von Security-by-Design zu Privacy-by-Design

In den Wochen und Tagen vor und nach dem 25. Mai 2018 war jeder E-Mail Briefkasten mit Nachrichten wie “DSGVO-Update” oder “Aktualisierung unserer Datenschutzerklärung” gefüllt. Sie werden sich vielleicht wundern, warum Sie von inWebo bisher keine Informationen darüber erhalten, was wir in dieser Angelegenheit getan haben und wie vorbereitet wir sind.

InWebos Geschäft ist Identitätsschutz. Wir konzipieren und implementieren Cybersicherheitstechniken, um die Benutzeridentitäten unserer Kunden zu schützen. PIIs (Personally Identifiable Information) sind in unseren Systemen stark geschützt, wobei starke Verschlüsselung, Krypto-Server, Firewalls usw. verwendet werden. DSPR-Anforderungen in Bezug auf Sicherheit werden erfüllt und übertroffen. Die DSGVO ist jedoch viel mehr als das. Deshalb mussten wir den Weg von unserem Ausgangspunkt “Sicherheit durch Design” zu einem “Datenschutz-nach-Design” gehen.

Hier sind die verschiedenen Themen, die wir angegangen sind und wie unsere Vorgehensweise ist:

  • Zustimmung des Benutzers zu Datenverarbeitungszwecken: Als B2B-Anbieter von Authentifizierungslösungen sammeln nicht wir Daten von Endnutzern der Lösung, sondern nur unsere Kunden. Wir erfassen Daten von Administratoren, wenn sie ein Konto für ihr Unternehmen erstellen und dies nur, um dieses Konto zu erstellen und Zugriff auf das selbige zu gewähren.
  • Minimale Datenmenge: Wir speichern nur die Benutzerdaten in unseren Systemen, die für unsere Kunden erforderlich sind, um die Authentifizierungslösungen, die wir ihnen zur Verfügung stellen, zu bedienen und zu überwachen, wie zum Beispiel Benutzername, E-Mail-Adresse und Authentifizierungsnutzungsdaten (Uhrzeit und Datum, IP-Adresse, Authentifizierungsstatus). Es liegt in der Verantwortung unserer Kunden, anonyme Benutzernamen zu verwenden und keine E-Mail-Adressen zu speichern, wenn sie die Funktion “PIN per E-Mail zurücksetzen” nicht verwenden.
  • Data Governance: Das war ein Vorteil der DSGVO, da wir eine Richtlinie für Datenverwaltung und Datenspeicherung defineren mussten. Wir haben jetzt unsere Aufbewahrungsfristen für Daten standardisiert: standardmäßig werden Authentifizierungs- und andere Nutzungsdaten ein Jahr lang aufbewahrt. Außerdem werden alle Daten des Unternehmenskontos maximal 6 Monate nach Ablauf eines Unternehmenskontos gelöscht. Kunden, die eine längere Aufbewahrungsdauer benötigen, z.B. für langfristige Sicherheitsanalysen, können zusätzlich eine Archivierungsoption abonnieren.
  • Zugriff auf Daten und Rückverfolgbarkeit: Da wir die Authentifizierungsplattform betreiben und wir für einige Aspekte der Lösung auf Dienstleister (unter anderen E-Mail-und Hostingdienstleister) angewiesen sind, mussten wir die Richtlinien für den Zugriff auf Daten sowohl für uns selbst als auch für unsere Dienstleister definieren und durchsetzen. Dienstanbieter haben ihre eigenen Erklärungen zur Einhaltung der DSGVO abgegeben und wir haben dafür gesorgt, dass diese mit unseren Zielen und Praktiken vereinbar sind. Was uns betrifft, greifen wir standardmäßig niemals auf Benutzerdaten zu, es sei denn, ein Kunde verlangt dies von uns, z.B. um ein Problem zu beheben. Wir haben festgelegt, wie unsere operativen Teams solche Anfragen autorisieren und protokollieren müssen.
  • Datenschutz: Kritische Daten wie Authentifizierungsfaktoren werden in unserer Plattform mit Krypto-Servern (HSMs) verschlüsselt. Benutzernamen sind in der Regel keine kritischen Informationen (wenn dies der Fall ist, liegt es in der Verantwortung unserer Kunden, stattdessen Aliase zu verwenden), und sie werden im Klartext benötigt, z.B. um Suchanfragen auszuführen. Andere Bezeichner wie E-Mail-Adressen oder Namen der vertrauenswürdigen Geräte, sind in der Regel keine kritischen Informationen, wir haben uns aber dennoch entschlossen, sie während der Speicherung zu verschlüsseln.
  • Recht (auf Zugang, Bearbeiten, Vergessen): Wir kennen die Endnutzer unserer Kunden nicht und haben daher keine Möglichkeit, Anfragen die wir von Endnutzer auf unserer Plattform erhalten, zu vergleichen oder zu überprüfen, ob eine solche Anfrage legitim ist. Wenn einer unserer Kunden ein Authentifizierungsprofil für einen Benutzer in unserer Plattform erstellt hat, liegt es in unserer Verantwortung, nicht darauf zuzugreifen, es nicht zu ändern und nicht zu löschen. Daher stellen wir unseren Kunden die nötigen Tools und Prozesse zur Verfügung die sie benötigen, um die Anfragen ihrer Nutzer selber zu beantworten, z.B. über eine API-Funktion zum Löschen von Benutzerdaten in den Authentifizierungsprotokollen unserer Plattform. Dennoch haben wir eine E-Mail-Adresse für Datenschutz- und PII-bezogene Anfragen von Endbenutzern erstellt. Wir werden unsere Rolle darauf beschränken auf E-Mails zu antworten, die den Benutzer auffordern, seine Anfrage an sein Unternehmen oder Dienstleister zu senden.
  • Aktualisierung unserer Datenschutzerklärung und allgemeinen Geschäftsbedingungen: Wir haben unsere Datenschutzrichtlinie und Allgemeine Geschäftsbedingungen im Januar 2018 aktualisiert, um Änderungen die sich aus unserer DSGVO-Einhaltung ergeben, zu berücksichtigen.

Starke Authentisierung – jetzt!

Posted by | News | No Comments
2fa Jetzt  

inWebo ist der gemeinnützigen Initiative Starke Authentisierung – jetzt! beigetreten. Namhafte Experten von Verbänden, Vereinen, Unternehmen und Institutionen haben sich zusammengefunden, um den Einsatz von starken Authentisierungsmechanismen im Internet zu fördern. Hierbei sollen Nutzer und Anbieter von Online-Diensten sensibilisiert und bei der Einführung von sicheren Authentisierungsverfahren unterstützt werden. Mehr Informationen finden Sie hier oder unter https://2fa.jetzt.

“Starke Authentisierung – jetzt!” weist auf Aktionen im Rahmen des European Cyber Security Month (01.-31. Oktober 2017) hin, die Nutzer über starke Authentisierungsmechanismen im Internet informieren und Anbietern von Internetdiensten die Unterstützung dieser Sicherheitstechnologien erleichtern.

A new Log API

Posted by | News, Tutorials | No Comments

inWebo provides a Log API so that you don’t have to export activity logs manually every day or every week. Logs are automatically made available in your collect and analytics tools.

inWebo Log API gives access to logs for a given service. Authentication to the API requires the same client certificate as the other inWebo APIs. Following log categories are available:

  • Authentication
  • Actions related to authentication devices (activation, online OTP, notification requests)
  • User management
  • Service configuration and Administration

With a call to the Log API, you can specify start and end dates, make page requests, or filter results by log category. Each record in the result is provided as a JSON table containing the following data:

  • Method used (authenticate, loginCreate…)
  • Result (OK, KO…)
  • User login
  • Time and date
  • IP address (when available)
  • Authentication device used
  • Authentication device identifier

Contact inWebo if you would like to activate this option for your authentication service.

Biometry as a second authentication factor

Posted by | News, Tutorials | No Comments

Following Apple’s introduction of a fingerprint sensor on iPhone 5s in 2013, smartphones increasingly come with a biometric sensor. Market research firms expect that 100% of the installed base will have some form of embedded biometrics by 2020 – this is not yet a commodity, but it will come fast. inWebo has therefore upgraded its solutions to support biometry as a second factor. The option is available on request to all customers, existing as well as prospects still evaluating inWebo (free trial).

Upon activation, the biometry option offers 2 alternatives, “biometry enabled” or “biometry forced”. The former applies to services that require users to enter a PIN as a second factor. Users who opt for it replace that PIN with biometrics. The latter mandates biometry as the second factor.

Biometry Settings

inWebo support of biometry as a second factor can be leveraged with

  • inWebo Authenticator version 4.2.0 or higher. The App supports Apple TouchID, as well as fingerprint sensors on Android Marshmallow (6.0+) smartphones.
  • inWebo mAccess version (0.)2.8 or higher. Developers can use mAccess library to support fingerprint biometry in their App but also virtually any kind of biometry (voice, face…), as long as it is implemented with a “match on card” mechanism (i.e. the biometric data is stored and verified locally on the smartphone). The library documentation provides a complete implementation for fingerprint sensors.

Please contact inWebo if you would like to easily add biometry as a second authentication factor for your services or applications.

DACH expansion + IT-SA 2016

Posted by | News | No Comments

Paris and Frankfort, October 3rd 2016 – inWebo is pleased to announce the appointment of Carlos Pinilla as a VP of Sales for the DACH Region: Germany, Austria, and Switzerland.

Mr Pinilla is a seasoned IT-security professional, having been among others a regional sales & marketing director for Utimaco, an Aachen (Germany) based hardware security module (HSM) vendor, and a partner of inWebo.

Based out of Frankfort, Mr Pinilla will spearhead inWebo development by building a channel of selected security partners, software vendors, and system integrators. As one of its first appearances in the Region, inWebo will be present at the IT-SA security show in Nuremberg October 18-21.

www.inwebo.com  –  sales@inwebo.com

SailPoint IdentityIQ supports inWebo multi-factor authentication

Posted by | News | No Comments

San Francisco & Paris, June 30, 2016 – Sailpoint (www.sailpoint.com) and inWebo have completed interoperability tests to use inWebo as an Identity Provider (IDP) for IdentityIQ, SailPoint’s popular identity governance suite.

The integration relies on SAML v2 support by IdentityIQ and inWebo. The integration “how to” documentation is available on inWebo developer website.

Customers can now use inWebo robust and convenient multifactor authentication to protect users access to IdentityIQ.

New Shibboleth plugin

Posted by | News | No Comments

Paris and San-Francisco, February 2nd, 2015 – inWebo has just released a plugin for the Shibboleth opensource web SSO and identity federation project. This plugin allows large organizations using Shibboleth to instantly benefit from inWebo secure & convenient authentication methods, where users can sign in easily and safely from their mobile phones, tablets, computers… One of many available authentication options allows a user to sign in securely (2-factor authentication) from their tablets or laptops without installing anything on their personal devices. The plugin consists in a java resource that an organization just adds to their Shibboleth deployment (version 2.4.3 or later).  The plugin will be found on the Shibboleth community resources wiki, as well as on inWebo developer website. It’s already available upon request for immediate deployments, and evaluation projects.