Fingerprint readers are returning:
We were discussing identity management without login screens.
We elaborated on the following three components as necessary for the alternatives:
1) user knowledge based component
2) server issued dynamic component
3) convenience factor
Biometrics becomes an important convenience factor for identity management when the technology to read them does not remain as restricted as they have been.
For example, Civic identity management which is based on blockchain ledger enables users to login with their fingerprints. There are a few technological advancements that's fueling this trend to return.
First, the erstwhile fingerprint reader devices are no longer space constrained. Today these readers can be part of the visual display of the screen and yet remain unintrusive for the most part. The world's first phone with a fingerprint scanner built into the display is now out. By embedding the fingerprint sensors into the displays, they are now more robust than they were with the earlier readers. Fingerprints have long been associated with the highest form of convenience but they were not fully utilized due to the limitations of the readers. They improved convenience by reducing the login experience to one-touch.
Second, the availability of a distributed ledger does away with a password database, This form of improvement enabled Civic to allow users to be recognized merely by their thumbprint while the digital identity was attested.
The mechanics of attestation is now achieved with a Merkle tree where the root hash is converted to a valid block chain address using the additive property of the Elliptic Curve Cryptography:
  k-priv + h = kattest
This allows the privacy for both the user and the validator to be protected.
#Merkel tree
every leaf node has hash of associated data block
every non leaf node has hash of labels of leaf nodes

We were discussing identity management without login screens.
We elaborated on the following three components as necessary for the alternatives:
1) user knowledge based component
2) server issued dynamic component
3) convenience factor
The last component above is the determining factor in why dynamic challenge questions cannot be a single and complete replacement to logins and passwords. The questions can be generated dynamically by the server such as from a list of ten questions that only the user can answer and the questions do not even need to have static answers, yet they cannot be as simple as the username and password. Moreover, people like to use their email or phone numbers for their username, something that does not seem likely to change although it adds to vulnerability by tying a centralized option for resetting all accounts.
We now consider blockchain technologies for identity management as per IBM. We discussed earlier that we can persist a token/passcode/password/private-keys/HTTP-Links for the user to login in a blockchain like database, we will have no need to maintain or manage these ourselves. Alternatively, we could consider using encryption-decryption-based and server issued-and-verified claims but without requiring a centralized server.
The benefits of identity with blockchain for consumers include:
 - convenience for accessing services and resources
 - better protection of privacy
 - greater control of personal data
The benefits for businesses include:
 - reduced risk and cost of data breach
 - efficient compliance management and governance
 - easier onboarding of customers
The benefits for regulators include:
- standardized processes
- prompt auditing
- compliance control
Find the largest rectangular sub-matrix having sum divisible by k.
The naive approach is to exhaust all the rectangular sub matrices to find the sums. check that the sums are divisible by k and then update the max of the rectangular size found so far.
This appears something like
int GetLargest(int[,] M, int R, int C, int k)
{
int max = 0;
// Every element forms the top left corner of a rectangular area of different sizes
for (int i = 0; i < R; i++)
  for (int j = 0; j < C; j++)
{
   int kx = i;
   int ky = j;


    for (int m = kx; m < R; m++)
         for (int n = ky; n < C; n++)
    {
           int sum = GetSum(M, i,j,m,n);
           if (sum % k == 0)
           {
                    int size = GetSize(i,j,m,n);
                    if (size > max)
                        max = size;
           }
    }
return max;
}

We were discussing identity management without login screens.
If we can persist a token/passcode/password/private-keys/HTTP-Links for the user to login in a blockchain like database, we will have no need to maintain or manage these ourselves. Alternatively, we could consider using encryption-decryption-based and server issued-and-verified claims but without requiring a centralized server.
Today we continue discussing http links instead of codes. The notion of server issued one time authentication links is effectively demonstrated by Slack. This application presents a login button that dynamically fetches a login url from the server for that account on that device. It does away with the need to specify the password. An initial onetime registration step may alleviate redundant routine during each sign on and in that sense, the security of this mechanism can be hardened.
The http link issued from the server could be enhanced with a PIN that the user knows. This adds more security. This then becomes the equivalent of PIN and OTP code that the users specify.
The OTP code could also be generated from a local application or device if it was pre-registered with the authentication server.
So far we have elobarated on the following three components
1) user knowledge based component
2) server issued dynamic component
3) convenience factor
The last component above is the determining factor in why dynamic challenge questions cannot be a single and complete replacement to logins and passwords. The questions can be generated dynamically by the server such as from a list of ten questions that only the user can answer and the questions do not even need to have static answers, yet they cannot be as simple as the username and password. Moreover, people like to use their email or phone numbers for their username, something that does not seem likely to change although it adds to vulnerability by tying a centralized option for resetting all accounts.

#codingexercise
Find the maximum product of an increasing subsequence
Since the input is all positive, the longest increasing subsequence will also give the maximum product.
double GetProductIncreasingSubsequence(List<double> A, int n)
{
   Debug.Assert(A.All(x => x  >= 0));
    var products = new List<double>();
    for (int i = 0; i < n; i++)
        products.Add(A[i]);
    Debug.Assert(products.Length == A.Length);

    for (int i = 1; i < n; i++)
        for (int j = 0; j < i; j++)
            if (A[i] > A[j] &&
               products[i] < (products[j] * A[i]))
                products[i] = products[j] * A[i];

    return products.Max();
}

We were discussing identity management without login screens.
If we can persist a token/passcode/password/private-keys/HTTP-Links for the user to login in a blockchain like database, we will have no need to maintain or manage these ourselves. Alternatively, we could consider using encryption-decryption-based and server issued-and-verified claims but without requiring a centralized server.
We refer to detail discussion here: https://1drv.ms/w/s!Ashlm-Nw-wnWtTfVe0YlXo5LKceK
Today we discuss how servers can help mitigate password rememberance for customers. In particular we discuss http links instead of codes. The notion of server issued one time authentication links is effectively demonstrated by Slack.
When the application is launched on the mobile device by the user, she is displayed a button to request Slack to send a link.Slack then seems to generate a random code that is the equivalent of a one time passcode and this is passed as a html link for the user to click, When the link appears on the mobile device either using SMS or push notification, the html link then propagates to the web view of the application as a launch parameter. The server generate code is not a replacement for OAuth tokens and may very well be used in conjunction with that protocol but the notion that we can display an html link which is far more convenient to the user than an OTP code is definitely an improvement in that sense. Most SMS applications and push notifications are able to differentiate when a link is sent. Although those applications may not be secure, the server generated code is definitely unique and cannot be spoofed. If the server issues these codes just the same way as tokens, it may be considered secure. An initial onetime registration step may alleviate redundant routine during each sign on and in that sense, the security of this mechanism can be hardened.

We were discussing Remme and its use of blockchain for distributed identity management. Blockchain is a ledger that the public can use to verify grants and revocations without a centralized ownership. It mitigates tampering and can is therefore an irrefutable proof. Remme replaces passwords with an application which essentially manages certificates. This certificate exchange is similar to the way browsers work except that there is no certificate authority hierarchy. The PKI infrastructure relied on an issuing authority hierarchy and the blockchain helps mitigate that. Remme seems to use Bitcoin in its current version instead of the public blockchain but what they have not explained is how different it is from Google's initiative in the certificate transparency project. There is no denying that Blockchain can prove a great storage for storing and processing digital identity data. Moreover, applications today currently find a way for passwordless mechanism by having the server generate random information which the application with the consumer can then use. While these can be based on SMS and push notifications, they need not be based on six digit one time passcodes. They can be based on links instead of codes with the links providing sufficiently unique random hash that it works like a password especially if the mobile application with the consumer individual can open it in a browser. While some applications may be prevented from their appstore policies to open a link that can lead to a marketplace outside the application, there is no restriction to using SMS to send a link. Although SMS has its own limitations as a channel of notification, the idea that the server creates a passcode or passhash to admit the individual is not new. The only difference is whether there is a central authentication server and a database that keeps track of timestamp, individual, passcode or passhash and a flag that it has been used. When an individual sends this information to the server, it calculates how much time has expired and whether the flag that this one time entry has been used, is set. The individuals submission of the launch parameters which includes this information is then directly treated as a login credential to allow it. This notion is very similar to how tokens are issued and validated today. The token issuing protocol such as OAuth never mandated a database for tokens in the first place even if they are bearer mode and last up to an hour although the protocol does call out to reduce the time for the token expiration and use scopes with the tokens. Blockchain provides this mode for credential storage. Since the credentials are issued by the server for a short time when the end user application with the individual launches, there is no need for the user to remember the passwords. This technique is very powerful in having users get notifications to what amounts to a seamless entry to their resources.  The only question that remains is in what cases will a user interface provide comfort to the user with a process of actual or simulated signing in?

Blockchain Technology has been used to decentralize Security and proves to be great for identity management. A blockchain is a continuously growing list of records called blocks which are linked and secured using cryptography. Since it is resistant to tampering, it becomes an open distributed ledger to record transactions between two parties. In identity managements it avoids the use of an authentication server and a password database. Each device or user media is given a private key which is guaranteed to be unique and a control from that device such as the click of a button is the equivalent of signing in. Identity management user interface therefore becomes far simpler than what users are currently frustrated with today. Even in such scenarios, the security is only improved when the user mentions something only she knows.  As stated earlier, security is about knowing as well as having. Therefore, the user interface even with blockchain technology could do with some visual aid to the process of signing in. This is particularly more meaningful  where user interactions matter and the identity management is not for automations. Here the use of the interface is a visual equivalent to securing the private key with a password.
One such user interface could be the use of solving a captcha that not only the machines but also nobody other than the owner can answer. As an example, we enter one time passcodes in the form of six digit numbers. Instead if there were a panel of nine tiles which only the individual can select six and in a sequence that is unique and known only to the individual, then it becomes the equivalent of a password. Even One time passcodes relayed from the authentication server could be considered a passwordless equivalent to the conventional login. Here we are merely making it easier for the user to answer based on his habit of selection rather than his reliance on remembering the password. In this case, we have
    function append(id) {
      var text = $("#password").val();
       if (!text)
       {
            toggle();
            $("#password").val(id);
       }else{
            if (text.length < 6) {
             $("#password").val(text+id);
            }else{
                toggle();
            }
       }
    }
    function toggle() {
    var passwordField = document.getElementById('password');
    var value = passwordField.value;
    if(passwordField.type == 'password') {
        passwordField.type = 'text';
    }
     else {
       passwordField.type = 'password';
     }
       passwordField.value = value;
    }

We were looking at some of the search queries that are collected from the community of those using  logs from an identity provider:

We were discussing how the additional lines around a match provide additional attributes that may now be searched for direct information or indirectly tagged and counted as contributing towards the tally for the labels.
In the logs, we can leverage protocols other than http and oauth. For example, if we use SAML or other encrypted but shared parameters, we can use it for correlations. Similarly, user agents generally give a lot of information about the origin and can be used to selectively filter the requests. In addition to protocols, applications and devices contributing to request parameters, cookies may also store information that can be searched when they make it to the logs. Most mobile devices also come with app stores from where packet capture applications for those devices can be downloaded and installed. Although the use of simulator and live debugging does away with the use of packet capture applications, they certainly form a source of information.

The logs for mobile devices can also be shared especially if they are kept limited and small with a finite number of entries.

48) Pivoting – Request parameters that are logged can be numerous and often spanning large text such as for tokens. Moreover, pivoting the parameters and aggregating the requests based on these parameters becomes necessary to explore range, count and sum of the values for these parameters. In order to do this, we use awk and datamash operators.

49) grouping selections and counting is enhanced with awk and datamash because we have transformed data in addition to the logs. For example, if we are searching for http requests grouped by parameters with one for each request, then we could include the pivoted parameters in aggregations that match a given criteria.

50) In the absence of an already existing tags for these pivoted request parameters and their aggregations, we can now create new tags with search and replace command in the same logic as above but with piping operation.

#codingexercise:

Determine fourth order Fibonacci series:
T(n) = Fib (Fib(Fib(Fib(n))))

generate maze

for (int i=1; i<ROWS; i++) {
  for(int j=1;j<COLS;j++) {

    String c = (Math.floor((Math.random()*2)%2)) ? "|" : "__";

    Console.Write(c);
  }
  Console.Writeline("<br/>");
}