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/>");
}

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

In particular, we were looking for a few lines above and below a match to include associated event attributes. This is easy with a streaming operation in the shell command with "grep –C<N> literal file".  In SQL this becomes slightly complicated involving a recursive common table expression. A nested query might work too provided the identifiers are continuous.
For example:
SELECT a.*
FROM Table1 as a,
(SELECT id FROM Table1 WHERE message LIKE '%hello%') as b
WHERE a.ids BETWEEN b.id-N AND b.id+N;
On the other hand by using max(b.id) < id  and  min(b.id) > id as the sentinels, we can now advance the sentinels row by row in a recursive query to always include a determined number of lines above and below the match
For example:
with sentinels(prevr, nextr, lvl) as (
  select nvl((select max(e.employee_id)
              from   hr.employees e
              where  e.employee_id < emp.employee_id),
              emp.employee_id) prevr,
         nvl((select min(e.employee_id)
              from   hr.employees e
              where  e.employee_id > emp.employee_id),
              emp.employee_id) nextr,
         1 lvl
  from   hr.employees emp
  where  last_name = @lastname
  union all
  select nvl((select max(e.employee_id)
              from   hr.employees e
              where  e.employee_id < prevr),
              prevr
         ) prevr,
         nvl((select min(e.employee_id)
              from   hr.employees e
              where  e.employee_id > nextr),
              nextr
         ) nextr,
         lvl+1 lvl
  from   sentinels
  where  lvl+1 <= @lvl
)
  select e.employee_id, e.last_name
  from   hr.employees e
  join   sentinels b
  on     e.employee_id between b.prevr and b.nextr
  and    b.lvl = @lvl
  order  by e.employee_id; 
 adapted from Oracle blog by Chris Saxon

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.

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

Some other interesting events for identity include:

45) looking for a few lines above and below a match to include associated event attributes. This is easy with a streaming operation in the shell command with "grep –C<N> literal file".  In SQL this becomes slightly complicated involving a recursive common table expression. A nested query might work too provided the identifiers are continuous.
For example:
SELECT a.*
FROM Table1 as a,
(SELECT id FROM Table1 WHERE message LIKE '%hello%') as b
WHERE a.ids BETWEEN b.id-N AND b.id+N;
On the other hand by using max(b.id) < id  and  min(b.id) > id as the sentinels, we can now advance the sentinels row by row in a recursive query to always include a determined number of lines above and below the match

46) grouping selections and counting now works successfully with the above logic. For example, if we are searching for http requests in a long that span multiple lines one for each request parameter, then we could include the associated parameters to corresponding to the requests that match as tags to group the requests. For example

grep -C7 match file | grep tag | cut -d"=" -f1 | sort | uniq -c | sort -nr

47) In the absence of an already existing tags, we can now create new tags with search and replace command in the same logic as above but with piping operation..