KeyChest blog
KeyChest updates, information, and write-ups

KeyChest – Unifying Public and Private Keys

KeyChest has started as an easy to use HTTPS monitoring service. What we are aiming for is a general purpose key management service, which can look after your public as well as internal web encryption keys.

<p>KeyChest has started as an easy to use HTTPS monitoring service. What we are aiming for is a general purpose key management service, which can look after your public as well as internal web encryption keys.</p><p>Ever since KeyChest got its first users, we were asked if it can be used for internal keys. Our initial approach was to provide on-premise instances, which gave potential users a complete autonomy in terms of separate database and dedicated processing power. This is what we still offer as the Enterprise option. But this option asks a lot from users as they have to, at least to some degree, look after their KeyChest.</p><p>As we developed new features it became obvious that we need another option – more flexible, lightweight, low-maintenance. That’s where independent agents, extending the reach of KeyChest audit engines, come from. As we are close to launching KeyChest agents, here’s an introduction.</p><p>Agents will be generally available from the beginning of July 2019.</p><h2>Proxy Agent</h2><p>We wanted agents to be as small and platform-independent as possible. The smaller they are, the easier they are to install, maintain, and update. The platform independence means there is almost no encryption inside (except for an ability to create a secure encrypted channel). Neither it can use low-level networking or other platform-dependent support. Agents will still have to be able to read / write to files and connect to the main KeyChest service, but even file-system access has to be limited to common functionality.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Communication and block diagram of KeyChest agents." src="/storage/wink/images/778XBs0QtPgdumuxZolrUXS8BwrLwPLPVa6bzduF.png"><p>Communication and block diagram of KeyChest agents.</p></div><p><br></p><p>The core of KeyChest agents comprises the following 3 subsystems:</p><ol><li><strong>Logging</strong>&nbsp;– a robust logging, which stores activity logs locally as well as posts them to the KeyChest service is simply a must for efficient management. Detailed information is what you need when in trouble – whether it’s for KeyChest users or for our support helping you out.</li><li><strong>Proxy operation</strong>&nbsp;– the actual audit of secure services requires a strong control over the networking, something that is platform dependent and we are regularly updating it. It means agents must work as transparent proxies for traffic generated by the KeyChest Audit Engines.</li><li><strong>Local control</strong>&nbsp;– agents are gateways into your internal networks and we want to give you as much control as possible over what they can be used for. We are putting restrictions on the ports they can connect to, the address ranges they can use, and so on. This information is in local configuration files, which can be locked-down so only you can change them. We also plan to give as wide access to the source codes of agents as possible.</li></ol><h2>Logging</h2><p>We see logging and ability to audit collected logs as one of the most important aspect of any software and network services. When we started implementing the agents, the first thing we did was a robust logging framework.</p><p>Logging produces JSON formatted messages that provide much better quality of “raw” data. This has massive implications on log audits as all the parameter values from logs are natively stored as separate indexed items. (Internally, we use Splunk for audits. Since we started using JSON logs, visualization and inspection of tens or hundreds of thousands log records were actually fun. The simplicity of selecting any of the log parameters and focus analysis around them gives you a good chance to spot irregularities and issues to look into.)</p><p>The success of any audit of logs depends on the quality of the data and being able to quickly identify where it came from. Each log entry therefore contains:</p><ul><li>time of logging</li><li>time of event</li><li>event code – severity of the message and a unique code (e.g., ERR0043)</li><li>host machine – name and its IP address</li><li>version of the software (agent); and</li><li>process – if the software uses multiprocessing.</li></ul><h2>Proxy Operation</h2><p>This is possibly a more interesting part of KeyChest agents and it still amazes me how simple can it look from outside.</p><p>Each agent controls the traffic and any requests coming from the KeyChest.net service. Details of audit requests are sent to agents so they can block those not complying with agent’s local configuration file.</p><p>Agents regularly connect to keychest.net to request audit “jobs”. When they receive a valid description of an audit job, they will launch a proxy, which connects to the audit target (downstream) and to KeyChest (upstream). Once the audit is completed, the proxy is terminated and the agent can re-use its port.</p><p>Internal network discovery is treated separately. We plan to implement a range of discovery methods based either on:</p><ul><li>internal database of certificates (e.g., LDAP storage of your PKI system); or</li><li>internal DNS zone.</li></ul><p>Discovered services are sent to the KeyChest service so it can start scheduling regular audits.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Communication diagram of KeyChest agent in the reverse proxy mode " src="/storage/wink/images/sQ2qkrWhx9mUZ3WAhaLGFz0ICtFHWa15ApZsBskq.png"><p>Communication diagram of KeyChest agent in the reverse proxy mode </p></div><h2>Agent Installation</h2><p>Agents are provided as one-file packages. You can run them by hand or invoke them with a scheduler like Linux cron. When it’s started for the first time, it will create an initial configuration and will try to register with KeyChest. Once completed, the agent will have its own unique API key and ID, which is in the form of an email address.</p><p>It will occasionally push its configuration to the KeyChest service, but nothing else will happen until it is associated with a KeyChest account. Once that happens, the service discovery and regular audits will commence automatically.</p><p><br></p>

Publication Date: 2019-06-24 10:02:00

KeyChest and Reliability

Those who have been with us for a while may know that we change the cloud provider to Digital Ocean in January. At the same time, we started experimenting with HA database cluster. And we learnt a lot.

<p>Those who have been with us for a while may know that we change the cloud provider to Digital Ocean in January. At the same time, we started experimenting with HA database cluster. And we learnt a lot.</p><p>A wise man would say that you learn most from mistakes and it's true that if things simply work, you are likely to be caught off-guard. We have been experimenting with HA database clusters for several months and believed we mastered the technology. Well, you can judge for yourself in this <a href="https://magicofsecurity.com/mysql8-cluster-and-networking-problems/" target="_blank">blog post of mine</a> :) One big lesson however was that you can't do much without information.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Netdata provides an excellent source of real-time system data." src="/storage/wink/images/ExX2VCY58lIiSEAzmTKNuxWXwyyjiR3CG86f0Mr8.png"><p>Netdata provides an excellent source of real-time system data.</p></div><p>We have eventually decided to use Netdata, which so far satisfied all our requirements. We can access detailed reports when we need them, all alarms are forwarded to our Slack and we have also included alarms and main system stats to the KeyChest web site. You can access those at <a href="https://keychest.net/status" target="_blank">https://keychest.net/status</a> . This page also includes notes about problems and planned system upgrades when we expect downtimes or issues.</p><p>Another aspect of the KeyChest monitoring is access to the application logs. We have completely re-factored logging in the KeyChest audit engine. The aim was to create data that is easy to analyse and query. We have decided to go for the JSON format, with simple text messages and separate parameters and implemented a new log dispatcher that collects logs from multiple audit processes.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="" src="/storage/wink/images/Xf9g3ndqb1yPAHX3e11ZdezDR4hAuvwYTR8COq3R.png"></div><p>Each log message uniquely identifies its source and the version of the KeyChest. It has two timestamps so we know when the logged event happened and when it was added to logs. All variable parameters are defined as separate JSON data items so we can automate analysis with very little loss of detail.</p><p>The analysis is crucial for effective use of any logs. In our case, we store logs locally in files to ensure they don't get lost due to networking issues and we also push the data to a Splunk instance for visualization and querying.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Splunk visualisation of memory use by KeyChest audit engine" src="/storage/wink/images/Alqm9WbBU1fi6fRTEo3uKIvf1EMsnP3oLwtuJTTZ.png"><p>Splunk visualisation of memory use by KeyChest audit engine</p></div><p>We really do put a lot of effort into making KeyChest a reliable service. Sometimes it feels like everything is stacked against us but we are making it better week by week. So if something doesn't work it only means we missed something and we'd love to hear from you!</p><p><br></p><p><br></p>

Publication Date: 2019-06-17 13:58:00

Can blockchain remove the need for an SSL certificate authority?

Blockchain is basically a chain of signatures. You create a digital signing key and sign data/transaction with it. It has nothing to do with trust.

<p>Let’s think about what blockchain does and what a certification authority (CA) does.</p><p>Blockchain is basically a chain of signatures. You create a digital signing key and sign data/transaction with it. Each new signature is over 2 items:</p><ol><li>the data/transaction you want to sign - it could be a string with a “public key” and “name”; and</li><li>the previous signature you created.</li></ol><p>CA verifies that a certain “name” belongs to YOU, that you own a “public key”, and binds the “name” and “public key” together with a digital signature. YOU can be a domain name, email address, an organisation, a physical person with a postal address, and so on. CA will use any of a number of methods to verify that the “name” is YOU. The signature at the end is the easy part.</p><p>So Blockchain can create a signature, but that is hardly enough to replace CA. But let’s say, we want use Blockchain. The first question would be - who verifies that the “name” is you, who will be responsible for the correctness, how you compare independent proves, if you expect more than 1.</p><p>On a side-note, good CAs will sign all their operational log as a “blockchain”, i.e., linked together. :)</p>

Publication Date: 2019-06-14 13:06:00

Is a password of 20 characters strong enough to use?

It could be but it may not, it depends on how random those 20 characters are. Let me demonstrate the thought with 2 common attacks on passwords.

<p>It could be but it may not, it depends on how random those 20 characters are. Let me demonstrate the thought with 2 common attacks on passwords. These attacks are:</p><ol><li>dictionary - using dictionaries of passwords someone else used before or words from “normal” dictionaries, including concatenations of 2 or more words;</li><li>brute-force - trying all possible combination of characters (letters, numbers, special characters), possibly using templates, e.g., first letter is capital, last is number, lower-case in the middle.</li></ol><p>So if you use 2–3 common words to get 20 characters’ password, then it will be weak.</p><p>If your password is random and not in any of the dictionaries (attack no 1 is impossible), it has to be long enough to withstand brute-force attacks.</p><p>In this case, a 20 characters’ long password made up from 70 different symbols (lower case, upper case, digits, special characters) is as strong as today’s encryption keys. Which means, it is “cryptographically secure” and it doesn’t make sense to go any further.</p><p>If you think Google represents industry standards, then its Google Authenticator uses secrets of 80 bits = 13 characters passwords as defined above. These secrets are used to compute one-time passwords.</p>

Publication Date: 2019-06-14 13:01:00

What could be done if all current Encryption could be broken and cracked?

If all current encryption were suddenly broken, that would be the end of it for encryption as we know it. With one exception - one-time pad.

<p>If all current encryption were suddenly broken, that would be the end of it for encryption as we know it. With one exception - one-time pad. One-time pad is a provably secure encryption that can’t be broken, but it has practical difficulties - it requires keys as long as the data.</p><p>There are, however, alternatives to encryption and there is also a saying “If you think encryption will solve your problem, you don’t know what is your problem.”.</p><p>If you want to “crack” encrypted data, you need to get the encrypted data first. The most likely defence would in this case be protection of the communication channels - whether by splitting data between 2 or more channels, making access to these communication channels hard, or hiding the fact that there is any data present (e.g., by mixing it up with random noise).</p><p>Practically - you can’t do much. Current encryption algorithms are hard-coded to critical business applications and it would be impossible to change much in less than 6–12 months.</p><p>We may be forced to think which data is sensitive and important and which data we actually don’t have to send or store in the first place. This is another great way of protecting us from getting hacked.</p>

Publication Date: 2019-06-14 12:57:00

What Is Encryption Domain

Encryption domain is simply a set of computers or other computing devices (or even people :) ) who share encryption key(s) allowing them to trust each other.

<p>Encryption domain is simply a set of computers or other computing devices (or even people :) ) who share encryption key(s) allowing them to trust each other.</p><p>It can be a master authentication key which can easily verify identities of entities within the encryption domain. Or it can be an encryption key, which allows access to encrypted data or communication.</p><p>The point of encryption domains is to create an environment where all entities within an encryption domain can automatically verify each other or share access to and create encrypted assets which can be accessed with the knowledge of “domain encryption key”.</p>

Publication Date: 2019-06-14 12:54:00

What is the SHA-256 fingerprint?

SHA-256 fingerprint is a digital fingerprint we use to compare two documents or to check if a document has been changed.

<p>It is a digital fingerprint we use to compare two documents or to check if a document has been changed.</p><p>It has a fixed length of 64 bytes (or characters, if you want), which encode 256 bits, each bit is either 0 or 1. Once calculated, it is unique for the data or file for which it has been created. While it is relatively short, it is practically impossible to compute any other document, which would have the same fingerprint.</p><p>The main properties of digital fingerprints, including SHA-256 are:</p><ol><li>It’s short - it is always 256 bits regardless of whether the original data is 100 bytes or 100 terabytes.</li><li>It’s impossible to compute a different data which would have the same fingerprint.</li><li>It’s impossible to compute the original data from the fingerprint.</li></ol><p>What it DOES NOT do - it doesn’t necessarily protect against discovering the original data, if the original data comes from a sufficiently small set. Attackers can simply try all possible data values and find a match. Let's take ZIP codes as an example. There are less than 100,000 5-digit zip codes in the USA and 1,000,000,000 zip+4 codes. It's trivial for your laptop to calculated SHA-256 fingerprints of all of them and compare them to the one fingerprint you want to "reverse". This approach is used to create "rainbow tables" - fingerprint tables of all possible values - used to crack our passwords.</p><p>From practical point of view:</p><p>- It DOES “hide” the original data (with the caveat above).</p><p>- It simplifies data search - it can speed up database queries when they are done with fingerprints, rather than the data itself.</p><p>- It is fast to calculate.</p><p>- If it’s too long for you, you can use only part of the fingerprint and it still works (too much detail possibly, but beware of the birthday paradox if you don’t want to end up with collisions -&nbsp;<a href="https://en.wikipedia.org/wiki/Birthday_problem" target="_blank" style="color: rgb(43, 109, 173);">Birthday problem - Wikipedia</a>).</p><p>The name also denotes the function used to calculated it (SHA-256), which is one of the family of functions called SHA-2 and which includes SHA-224, SHA-256, SHA-384 and SHA-512, where the number indicates the size of the fingerprints.</p>

Publication Date: 2019-06-14 12:41:00

What is certificate pinning

Some people argue that certificate pinning is a must to protect against sophisticated attacks. Some will say that it's pain in the bottom. But what is it actually?

<p>Some people argue that certificate pinning is a must to protect against sophisticated attacks. Some will say that it is a pain in the bottom. But what is it actually?</p><p>Certificate pinning is a mechanism that introduces "direct trust" between your web browser and a web server. When the web server (e.g., quora.com) provides a "pinning flag", your web browser will remember it and will warn you when you try to connect to the quora.com server again and it shows a warning if it detects a configuration change (i.e., someone attacks you or someone made a configuration error).</p><p>The usual verification of HTTPS is using standard X.509, which defines certificate verification via proxy, where the proxy is a “trusted authority”, or a CA. We, as users, don’t care which certificate is used so long as the trusted authority confirms it’s a good one. And as long as the trusted authority is trusted by our web browsers.</p><p>Pinning means that you only trust the certificate you have seen before. You may use the proxy for the first validation, or you can just say whatever it is, I trust it.</p><p>When you talk to the same server again, you only trust it if it uses the same certificate. If it’s a different one, it will raise an alarm even if the proxy says it’s a good one.</p><p>In a way, the concept of certificate pinning is direct trust, just like in PGP (if you’re familiar with this system).</p>

Publication Date: 2019-06-07 07:53:00

Reliability of Let's Encrypt

I have analyzed reliability of Let’s Encrypt using their own data in Spring 2018.

<p>It’s a good question especially after a recent&nbsp;<a href="https://community.letsencrypt.org/t/may-19-2017-ocsp-and-issuance-outage-postmortem/34922" target="_blank" style="color: rgb(43, 109, 173);">downtime of LE</a>&nbsp;that lasted more than a day, with 16 hours of the service basically unavailable. This is quite a serious outage, which will probably put LE behind most of other certificate provides as it makes it uptime just 99.8% on its own for this year.</p><p>As LE assumes that renewals are automated, you should never assume that LE services will be always available and design your own production automation accordingly.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Let's Encrypt planned updates and their actual duration." src="/storage/wink/images/bTp1ljxHT4oYcr6XKTB3GuGh5D7BQPEiFUGDQm3x.png"><p>Let's Encrypt planned updates and their actual duration.</p></div><p>Having said that, I don’t believe there is a real possibility of an outage, which would last more than a week so in terms of issuance and certificate renewals LE is likely to remain reliable if you plan and renew according to recommended timelines.</p><p>Other than that, you should consider operational limits of LE. I have written up&nbsp;<a href="https://keychest.net/content/letsencrypt_numbers_to_know" target="_blank" style="color: rgb(43, 109, 173);">many of them into one blog post here</a>.</p><p>You may also be interested in assurance in terms of potential damage caused by incidents. I haven’t found any authoritative reference for any such assurance yet.</p><p>I have analyzed reliability of Let’s Encrypt using their own data in Spring 2018. </p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Duration of &quot;full&quot; disruptions per month with incident detail at the bottom." src="/storage/wink/images/071NXyAp95YZ5uEw8iKcTsZHLAPIbzA6QcTsyVxR.png"><p>Duration of "full" disruptions per month with incident detail at the bottom.</p></div><p>I used a couple of charts above and the write-up is at <a href="https://dan.enigmabridge.com/lets-encrypt-uptime-is-99-9%E2%80%8A-%E2%80%8Aor-98-8-without-defects-in-2017/" target="_blank" style="color: rgb(43, 109, 173);">Let’s Encrypt uptime is 99.9% — or 98.8% without defects in 2017</a>. It shows that it was fully up and running only for 98.8% of time in 2017. Some disruptions were “partial” so only a subset of users would experience them.</p><p>Another important aspect are changes to the protocol and its implementation. Many users experienced problem in Q3 as LE set IPv6 as the primary protocol. It was used whenever it detected existence of an IPv6 address, regardless of whether it actually worked.</p><p>It certainly makes sense to deploy an external end-to-end monitoring to detect any potential issues early on - something like our <a href="https://keychest.net" target="_blank">KeyChest service</a> .</p>

Publication Date: 2019-06-07 07:41:00

What are disadvantages of Let's Encrypt

Letsencrypt is now installed on more than 50% of all webservers. This is mostly thanks to its adoption by many web hosting providers. We can also see it starts being used by large companies and enterprises. But what are the downsides?

<p>Letsencrypt is now installed on more than 50% of all webservers. This is mostly thanks to its adoption by many web hosting providers. We can also see it starts being used by large companies and enterprises. But what are the downsides?</p><p>First of all - certificates' (including Let's Encrypt certificates) main task is to prove the authenticity of their owner, e.g., a web server. There is no difference between Let’s Encrypt and any other certificate your browser can verify (DigiCert, COMODO, Entrust, etc), and all browsers can now verify Let’s Encrypt certificates.</p><h3>Rate Limits</h3><p>When we look at limitations of Let's Encrypt, they are mostly operational. There is one big disadvantage of Let’s Encrypt - rate limits. These restrict the number of operations you can do per second, hour, week, depending on the type of requests. The limits are most severe for the number of certificates you can issue per “registered domain”, e.g.&nbsp;keychest.net. <a href="https://keychest.net/content/letsencrypt_numbers_to_know" target="_blank" style="color: rgb(43, 109, 173);">I have described most of those limits here</a>.</p><h3>New management approach</h3><p>Further, when using a Let’s Encrypt certificate, there are significant operational differences, i.e., how you manage such a certificate on your server.</p><p>Let’s Encrypt uses a set of new protocols for automated certificate management. There are two important effects of that:</p><ol><li>The process of issuing a certificate is different from most other CAs, which require manual steps, notably proving that you are the owner of a given server.</li><li>The same process is designed to work fully automatically. Let’s Encrypt is about automation to keep the certificate issuance costs low. There’s always a question how much you need to automate something you do once a year or maybe once every two years, this may be one of the reasons why Let’s Encrypt certificates are valid only 90 days.</li></ol><p>As a result, you have to renew your certificates four times, but more likely 6 times a year (due to time overlap), but you can automate it, if you have the skills and/or support. I would also recommend&nbsp;<a href="https://community.letsencrypt.org/t/monitoring-the-state-of-certificates-cont/37764" target="_blank" style="color: rgb(43, 109, 173);">monitoring</a>&nbsp;that your automation works. (I have been active in this area so you can try our service&nbsp;<a href="https://keychest.net/" target="_blank" style="color: rgb(43, 109, 173);">KeyChest</a>, which is free for 500 domains and personal use.)</p><h3>Reliability (2017)</h3><p>I have also recently looked into the reliability of Let’s Encrypt certificate issuance and described some of the results in my blog <a href="https://dan.enigmabridge.com/lets-encrypt-uptime-is-99-9%E2%80%8A-%E2%80%8Aor-98-8-without-defects-in-2017/" target="_blank" style="color: rgb(43, 109, 173);">Let’s Encrypt uptime is 99.9% — or 98.8% without defects in 2017</a>. It’s actually quite good for a completely new system, but much worse than commercial CAs. I came up with 2 numbers: 98.0% and 99.9%, and the real truth is somewhere between them for vast majority of users. 99.9% is when Let’s Encrypt was up for at least some of its users, 98.0% when it worked flawlessly.</p><h3>"Color" of padlock</h3><p>As a side note. There is a special type of certificates - so called Extended Validation certificates, or EV certificates. When a server presents an EV certificate, browsers tend to show the company name, rather than a web address. You can see the difference below - a Let’s Encrypt certificate (top) and an EV certificate (bottom).</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Domain validated certificate will only show the domain name." src="/storage/wink/images/eAFJkLmTjFBA9f8uioMnzl8U3RjZlDntXSxMKIRo.png"><p>Domain validated certificate will only show the domain name.</p></div><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Extended validation (EV) certificate will show the company name." src="/storage/wink/images/DOStMD4PBhEl8gpAZ8mbbk46Nc3Rj8a5RoV6kOda.png"><p>Extended validation (EV) certificate will show the company name.</p></div><p><br></p><p><br></p>

Publication Date: 2019-06-07 07:24:00

KeyChest Update - June 2019

Having spent quite a few months working on the "invisible" code powering KeyChest, we have added two new reports - phishing threat and identity reports. But that is not all, we will finally add agents for monitoring internal networks.

<p>Having spent quite a few months working on the "invisible" code powering KeyChest, we have added two new reports - phishing threat and identity reports. But that is not all, we will finally add agents for monitoring internal networks.</p><hr><p>KeyChest is still a bootstrapping company powered by my time and savings. That means that there are too few heads for too many hats - as in any start-up - from marketing (or testing marketing options), looking for customers as we are aiming at B2B business model, answering your questions and request (and we are very grateful for any feedback you send our way) ... to adding new KeyChest features. This time I will focus on the technology.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="An overall report of phishing threat for all registered domains in an account." src="/storage/wink/images/P7cc9XYfssrbKyfzLuK8VGstlcuhAf1T5GstHld6.png"><p>An overall report of phishing threat for all registered domains in an account.</p></div><p>I have added two new reports to the KeyChest dashboard - identity report and phishing threat report. You can see the phishing report above and this is what happens behind the scenes.</p><h2>Phishing Threat Report</h2><ol><li>we use a customized <a href="https://github.com/elceef/dnstwist" target="_blank">dnstwist module</a> to generate variants of domain names. We continue processing those in batches of 500.</li><li>Each batch of up to 500 is checked against our global lookup table of all issued certificates and we keep domains for which we find at least one certificate - it doesn't have to be valid at the moment.</li><li>The domains left are then checked for valid DNS records, MX record (i.e., email server exists), and A/AAAA records - i.e., hostnames one can use to host web sites.</li><li>All the distilled information is stored in the KeyChest database ready for reporting.</li><li>We try to structure the reports to be a little easier to read. We categorize each of the found "potential threat" as High, Avg, or Low risk. We will probably revise the criteria but at the moment, the High Risk are all domains created as Homoglyph (this includes use of international characters that look similar to ASCII ones). Medium Risk are domains with a valid certificate, email server and a "web hosting" domain name.</li></ol><p>If you decide to invest $10/month or more, you will also be able to see details of all domains, like this.</p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Detail of phishing threats" src="/storage/wink/images/KR98yUOrQoAERrbAK0FeVoXrQPVtYIEAY0XSda9W.png"><p>Detail of phishing threats</p></div><h2>Identity Report</h2><p>Identity report is a new report that focuses purely on keys. It can therefore use our global database of certificate to its maximum effect. Keys (and certificates) are group by their names and the table shows the date of the first certificate as well as the last update and expiration. </p><div class="embedded_image" contenteditable="false" data-layout="default"><img alt="Detail of a digital identity history - the buttons on the right lead to detail cards." src="/storage/wink/images/90Xgc3d6YK4sNgeEcGDQOjQKXXcRSTLAXTPLpWO8.png"><p>Detail of a digital identity history - the buttons on the right lead to detail cards.</p></div><p><br></p>

Publication Date: 2019-06-05 21:12:00

Is Biometric authentication on smartphones secure?

No answer is universally correct but here’s two use-cases so you can pick which is more appropriate for you - PIN or fingerprint.

<p>No answer is universally correct but here’s two use-cases so you can pick which is more appropriate for you.</p><ol><li>PIN:</li><li class="ql-indent-1">you’re on the train and there are baddies looking for victims. It’s fairly easy for them to eavesdrop your PIN and then steal your phone, get in and sell your personal data &amp; passwords.</li><li class="ql-indent-1">On the other hand - if FBI needs to get a PIN to a locked phone, they may call an Israeli high-security start-up, pay tens of thousands of dollars to unlock it.</li><li>Fingerprint</li><li class="ql-indent-1">back on the train - it would be pretty hard and risky for low-skilled baddies to unlock your phone without using&nbsp;<a href="https://www.ccc.de/en/updates/2013/ccc-breaks-apple-touchid" target="_blank" style="color: rgb(43, 109, 173);">some hackers</a>&nbsp;to get a printout of your fingerprint, invert it, create a latex film …</li><li class="ql-indent-1">FBI will have no problem whatsoever, to get your fingerprint, create a latex copy and unlock the phone.</li></ol><p>PIN attacks have zero initial costs and can be instant. Fingerprint attacks will costs hundreds of dollars and some time. So the question is what is the pay-off and what the bad guys are after. :)</p><p><br></p>

Publication Date: 2019-06-01 20:21:00