When connecting to on-line banking sites, browsers such as the latest firefox-8.x can show some of the attributes of the SSL [secure sockets layer] certificate, which the bank's server sends to the browser to provide a public encryption key plus some level of trust that the key is actually being provided by the intended bank. After connecting to the bank's secure web site with a firefox-8.x browser, and before logging in, a user has a chance to examine the SSL certificate by clicking on the colored area to the left of the bank's URL. Then click "More Information", and then "View Certificate". (Other browsers may have other methods to examine this certificate.) Some on-line banking users check this certificate before logging in for every new on-line banking session, as a precaution that they are really communicating with the intended bank or its on-line server provider. Information that is provided includes the number of bits that the session's encryption algorithm's key will use, the date of issue and expiration of the certificate, its serial number, and so-called "fingerprints" of the certificate. Fingerprints are a kind of digest of all the data in the certificate, provide some degree of confidence that the certificate has not been altered, and are often shown as a string of hexadecimal digits (0-9,A,B,C,D,E,F). Firefox-8.x shows both the MD5 (message digest #5) and SHA1 (secure hash algorithm #1) fingerprints. By monitoring the attributes of the SSL certificates used by various on-line banks across many on-line sessions with those banks, one can detect some possibly interesting differences in the way different on-line banks handle their SSL certificates. E.g. Ally Bank declares up-front in the first informational window that Ally owns the web site. AmEx uses a third party web site provider, and it is this provider that is shown as the web site owner. Chase does not declare ownership of the web site in the preliminary info window, but the later certificate info windows show that JPMorgan is the holder of the certificate. AmEx and Chase use 128 bit session encryption keys, while Ally uses a 256 bit key. AmEx and Ally each use the same unique certificate from session to session (as shown by each of their unchanging SHA1 fingerprints), while Chase appears to have tens of different active SSL certificates that are dynamically allocated to different sessions, each with a different SHA1 fingerprint. Periodically, old SSL certificates will expire and new ones will be issued to the banks by the trusted certificate authorities, of which there are several. Questions that could be discussed related to these on-line banking SSL certificate issues include: [1] Is it more trustworthy for a bank to operate its own on-line banking as an in-house operation, or to farm it out to specialist third party on-line banking organizations? [2] Is it easier to trust an on-line bank that consistently uses the same familiar SSL certificate, or is there greater safety in a bank using multiple certificates that change from session to session? [3] Would it be a good idea for all on-line banks to declare their explicit ownership of their web sites within the SSL certificate info that users can quickly check before logging on?
Answers
It was posted in the General Discussion (Any off topic discussions) section of the forum.
Although there are surely more exciting topics, this post was not intended to be boring or to induce drowsiness. It contains enough detail to allow depositors previously unfamiliar with encryption certificates to examine them and to note how different financial institutions might treat their certificates differently.
The relevance to deposit accounts is the issue of trust. Most depositors need to trust that they are dealing with their intended banks and credit unions, and not some scam. They need to trust that their transactions are reasonably reliable and private.
In earlier simpler banking eras, this trust could usually be fulfilled by physically visiting the intended financial institution, looking the staff in the eye, and transacting on-site. Or we could usually depend on the USPS to reliably and privately communicate our banking transactions.
With the introduction of on-line banking, the game of trust significantly changed. Digital encryption provides privacy and reliability of on-line communications with banks. The trust that encrypted communication is proceeding with the intended financial institution is to a great extent provided by SSL encryption certificates.
Because encryption certificates are a behind the scenes mechanism, they are easily ignored by users of secure web sites. The post was intended to shine a little light on this component of providing depositors trustworthy on-line communications with their financial institutions. It was also intended to point out observed differences in the way different institutions might handle their encryption certificates, and how this might affect depositor trust.
I was particularly interested in other depositors' insights into whether they might consider a bank that uses a single encryption certificate for all their on-line sessions as more or less trustworthy compared to a bank that uses multiple certificates that change from session to session.
Out of curiosity I ran the initial post through the Gunning Fog index calculator, which measures the readilbility of English writing. The fog index is commonly used to confirm that text can be read easily by the intended audience. Texts for a wide audience generally need a fog index less than 12. Texts requiring near-universal understanding generally need an index less than 8. FWIW, the calculation on your text was 15.18.
Sorry to have doubted the source of the information but the initial post read like an excerpt from a thesis. You obviously have an understanding of an interesting topic, and thank you for sharing it.
I fell asleep reading all the run on sentences on a post that was copied from elsewhere without a link to the original material.
And this whole post is related to deposit accounts how?