Website presentation proof of authenticity and method for proving thereof

A proof of authenticity of a website presentation includes a presentation being retrievable from the local storage of the web browser. The presentation is presented together with the main presentation retrieved from the website, thereby the presentation proves authenticity of the main presentation with the first website (10B).

TECHNICAL FIELD

The invention relates to the field of brand impersonation through website cloning/spoofing/or otherwise faking, mostly used for phishing and avoidance thereof.

BACKGROUND

FIG.1depicts an example of a prior art trusted website and its presentation on the screen.

A web address20of a prior art trusted website22A, e.g., https://trusted.com, runs a JavaScript program30A1running a web browser28A on the user's computer.

A prior art website presentation12A of trusted website22A presented on a screen26A of web browser28A of the user's computer, presents web address20of trusted website22A, being according to the example https://trusted.com.

Website presentation12A of prior art trusted website22A further presents trusted content24A, such as a login screen requesting the user to provide user and password combination to login. The site https://trusted.com, also presents the last-login information showing the user when was the last time he logged-in to the site. This gives the user the confidence that he is indeed working with the true trusted site, assuming that a fake site could not have guessed the last-login date and time.

The user's computer displays the web address (URL) of the page currently viewed at the top address-bar of said user's computer. Examining the web address by the user is the current measurement to determine whether the page indeed belongs to the genuine website.

FIG.2depicts a fraudulent website and its presentation on the screen.

A web address20of a fraudulent forgery website22B of a server somewhere, example given, https://faked.com, runs a JavaScript30B1, on web browser28A of the user's computer.

The website presentation12B of fraudulent website22B includes web address20of the fraudulent website22B, e.g., https://faked.com being different. Website presentation12B of fraudulent website22B may further include the exact same content as the genuine site including the last login date and time, and content24B.

Website presentation12B of fraudulent website22B may look equal to the prior art trusted presentation12A except for a change in the web address20, being “faked” in the example. Thus, the prior art proof of authenticity constitutes the website address presented at the top of the page.

The term “phishing” refers herein to fishing information through the internet.

However, the website address is ineffective for the function of proving authenticity, and websites like fraudulent website22B utilize the similarity for phishing content from the user, such as passwords and credit card details.

There is a long felt need to provide a solution to the above-mentioned and other problems of the prior art.

SUMMARY

A proof of authenticity of a website presentation, including:a presentation being retrievable from the local storage of the web browser,wherein the presentation is presented together with the main presentation retrieved from the website.

The drawings are not necessarily drawn to scale.

DETAILED DESCRIPTION

The invention will be understood from the following detailed description of embodiments of the invention, which are meant to be descriptive and not limiting. For the sake of brevity, some well-known features are not described in detail.

The reference numbers have been used to point out elements in the embodiments described and illustrated herein, in order to facilitate the understanding of the invention. They are meant to be merely illustrative, and not limiting. Also, the foregoing embodiments of the invention have been described and illustrated in conjunction with systems and methods thereof, which are meant to be merely illustrative, and not limiting.

Security printing deals with physical printing of proof of authenticity added to the main content of printed items such as currency bills, banknotes, cheques, passports, etc. The printed proof of authenticity disables forgery thereof.

Similar to the security physical printing, a trusted website according to one embodiment of the invention includes a proof of authenticity added to the main content, being configured to avoid forgery.

FIG.3depicts a trusted website according to one embodiment of the invention, applying the example of the prior art trusted website ofFIG.1.

Web address/URL domain enumerated20of an exemplary trusted website10B, being according to the example https://trusted.com, runs a JavaScript program30A2on web browser28A of the user's computer.

A visual and audible element of website presentation10A of trusted website10B according to one embodiment of the invention, presented on screen26A and loudspeaker27, presents web address20, being https://trusted.com according to the example. Website presentation10A of trusted website22A further includes trusted content24A retrieved from trusted website10B, being the source of the content.

Trusted content24A may include a login screen with a user interface allowing the user to trustily provide the user's user and password combination to trusted website10B.

Website presentation10A of trusted website10B provides, further to prior art trusted presentation12A of prior art trusted website22A ofFIG.1, includes a visual and/or audible element presentation14A which may include an animation, such as two circles, functioning as an identification that content24A of website presentation10A indeed is the content of trusted genuine website10B.

FIG.4depicts the first and second steps of running the web address of the trusted website ofFIG.3for obtaining the identification ofFIG.3.

At the first step, being upon accessing web address20of trusted website10B, being according to the example https://trusted.com, JavaScript program30A2of trusted website10B run on web browser28A, and presents content24A on screen26A.

The term “local storage” refers herein to any memory, disc, server, cloud, etc., being accessible to web browser28A of the user's computer.

The above mentioned disc may as well be a disc of a server of a website. However, it is not the website from which the content was initially downloaded.

The local storage preferably constitutes a Domain Associated Storage, being a data storage and source that is associated with a given network domain, accessible only to client-code of that domain being JavaScript program30A2. Example of such Domain Associated Storage is the local-storage feature of modern browsers or cloud implementations of such functionality.

At the second step, JavaScript program30A2looks in the local storage26B of web browser28A whether an identifying presentation, such as a file, is stored.

At the first time the user accesses web address20of trusted website10B, local storage26B does not yet contain an identifying presentation.

FIG.5depicts the third step of running the web address of the trusted website ofFIG.3.

At the case local storage26B does not contain an identifying presentation, then at the third step, JavaScript program30A2downloads the identifying presentation from trusted website10B, as described following.

The server of trusted website10B includes a plurality of available presentations, namely14A,14B,14C, etc. At the third step, JavaScript program30A2is programmed to download only one presentation, say14A only, into local storage26B of web browser28A, being selected (32) from those presentations14A,14B,14C, etc.

Selection32of presentation14A may be random or manual selection by the user request. The selection of presentation14A may as well be applied by secret of selection.

Thus, the downloading and selection of the presentation running on user' computer28A and writing by the user of the presentation is unpredictable to any other web browser, such as to28B (ofFIG.7), thus presentation14A functions as an identifying presentation.

Program30A2may further add a code36A to identifying presentation14A. Each of code36A and of presentation14A may be written to local storage26B by the user via the user interface of program30A2. For example, the user may draw a picture, or write a passcode, and may record a voice, and may process any of the above.

Program30A2copies code36A if defined as36B, to local storage26B attached to identifying presentation14A.

At the fourth step, being after storing identifying presentation14A into local storage26B at the first running, JavaScript program30A2retrieves identifying presentation14A from local storage26B, being the retrieval source, and presents identifying presentation14A together with code36B if present on screen26A of web browser28A.

In the example ofFIG.5, code36B as presented is “1X” being an addition to presentation14A. Code36B may be type of the display of presentation14A, such as coloring presentation14B to green or three-dimensioned or rounded, such that the green color constitutes the secret code.

That is, the fourth step being after once retrieving identifying presentation does not retrieve identifying presentation14A again from website10B.

That is, the above mentioned local storage being a disc of a website, excludes website10B, from which identifying presentation14A has been already retrieved.

FIG.6depicts the second and next openings of the web address of the trusted website ofFIG.3.

At the second and at any further time the user's computer28A runs JavaScript program30A2, being at the second and other times web browser28A of the user's computer accesses website20, the following two steps apply.

At the first step JavaScript program30A2finds identifying presentation14A in local storage26B, and at the second step presents identifying presentation14A, which may include code36B, on screen26A.

Presentation10A of website10B utilizes protocol HTTPS (Hypertext Transfer Protocol Secure), which ensures a different local storage to each web address/URL domain. This is a basic feature in most modern web-browsers, in contrast to HTTP (Hypertext Transfer Protocol).

The term “plugin” refers herein to software component adding a feature to an existing computer system.

JavaScript program30A2may include prior art program30A1plugged to a software component31being a plugin adding the proof of authenticity to prior art program30A1.

Namely, JavaScript program30A1presents prior art trusted website22A ofFIG.1presenting trusted content24A only; and plugin31presents identifying presentation14A proving the authenticity of content24A to the user, and retrieves identifying presentation14A from local storage26B, and downloads identifying presentation14A to local storage26B.

FIG.7depicts a fraudulent website attempting to provide wrong content to the web browser of the user's computer.

Suppose a fraudulent website22C, which may be accessed by a fraudulent link https://faked.com, runs a JavaScript program30B2, being similar to JavaScript program30A2of trusted website10B, on web browser28A of the user's computer, and suppose fraudulent website22C as well includes the presentations of trusted website10B, namely14A,14B,14C, etc.; and JavaScript program30B2downloads only one presentation therefrom.

However, HTTPS provides the web browser of website22C does not allow access to local storage26B of web browser28A.

JavaScript program30B2of fraudulent website22C probably will select identifying presentation14B rather than14A familiar to the user, due to the unpredictable selection described above, and thus will present identifying presentation14B on screen26A at the fourth step.

Identifying presentation14B being unfamiliar to the user being familiar with identifying presentation14A, indicates unintended access to fraudulent website22C, thus alerts the user without actually alerting

Thus, identifying presentation14A functions as a passcode/proof of authenticity (Poa) of content24A.

Even though identifying presentation14A, familiar to the user, was stored in local storage26B by trusted website10B, JavaScript program30B2of fraudulent website22C cannot access identifying presentation14A, since JavaScript program30B2is not run by the website having web address20of trusted website10B, since the local-store is tightly associated with the original domain by the web browser.

As explained inFIG.6, only JavaScript program30A2finds identifying presentation14A and can write code36B, whereas JavaScript program30B2cannot find identifying presentation14A, since Protocol HTTPS ensures its separate local storage to that web address/URL domain.

In the figures and/or description herein, the following reference numerals (Reference Signs List) have been mentioned:numeral10B denotes the trusted website according to one embodiment of the invention;10A: presentation of trusted website10B;12A: prior art website presentation;12B: website presentation of fraudulent website22B;12C: website presentation of fraudulent website22C;14A,14B,14C: available visual and/or audible presentation, each may constitute an identification that website presentation10A presents the content of trusted website10B;20: web address;22A: prior art trusted website22A;22B: fraudulent website attacking prior art trusted website22A;22C: fraudulent website attacking inventive trusted website10B;24A: content including user interface, presented by trusted website10B;24B: wrong content including user interface, presented by fraudulent websites22B and22C;26A: screen including loudspeaker27of computer;26B: local storage of the web browser;27: loudspeaker of computer;28A: user's computer running on the user's computer;30A1: computer program such as JavaScript run by prior art trusted website22A;30B1: computer program such as JavaScript run by fraudulent website22B for attacking prior art trusted website22A;30A2: computer program such as JavaScript run by inventive trusted website10B;30B2: computer program such as JavaScript run by fraudulent website22C for attacking trusted website10B;31: software component being a plugin; computer program30A2may be a combination of computer program30A1and software component31;32: random selection;36A: code added by computer program30A2to identifying presentation14A of inventive trusted website10B;36B: code attached to identification presentation14A for being presented.

According to another embodiment of the disclosed technique, for each domain accessed by the local machine, a domain unique verification record (e.g., database record, file) is generated locally by the local machine and stored locally in the local machine, in a location exclusively associated with that domain. This domain unique verification record is generated for every domain and is unique therefore. This domain unique verification record is generated for every domain accessed by the local machine for the first time. When the local machine accesses that domain at a later time, since the domain unique verification record already exists for that domain, the local machine is not required to generate a new one. Instead, the local machine can simply access that domain's unique verification record associated with that re-accessed domain.

Each domain unique verification record has a domain unique visual representation associated therewith. The user has access to the domain unique visual representation associated with each one of the domain unique verification records and may change it at will, so that the user may better and easier recognize that domain unique visual representation the next time it is presented thereto.

When a phishing domain is accessed for the first time (e.g., via a link provided to the user), the local machine generates a phishing domain unique verification record for that phishing domain. The local machine further associates a new phishing domain unique visual representation with that phishing domain unique verification record. Thereafter, the local machine presents that phishing domain as a unique visual representation to the user. Since this phishing domain unique visual representation is highly unlikely to be recognized by the user as a domain unique visual representation that he is already aware of, the user shall have a strong indication that the fishing domain is not a genuine domain and he is likely to take appropriate actions accordingly.

According to a further aspect of the disclosed technique, the local machine does not involve the domain in the process of generating a domain unique verification record or in the process of associating a domain unique visual representation.

According to yet another aspect of the disclosed technique, the local machine may also store locally a criteria (e.g., indication, set of characters, set of characteristics) of authenticity for a previously authenticated domain (e.g., recognized as such by the user). When an imposter domain (e.g., phishing domain) is accessed for the first time (e.g., via a link provided to the user), the local machine generates an imposter domain unique verification record for that imposter domain which checks to see if it matches one or more verification characteristics which are associated exclusively with the genuine site (i.e., that the imposter site is attempting to resemble). If there is no match with the verification characteristic(s), the user and the owner of the genuine domain are notified that the imposter domain is not a genuine domain and the user is likely to take appropriate actions accordingly.

The foregoing description and illustrations of the embodiments of the invention have been presented for the purpose of illustration, and are not intended to be exhaustive or to limit the invention to the above description in any form.

Any term that has been defined above and used in the claims, should be interpreted according to this definition.

The reference numbers in the claims are not a part of the claims, but rather used for facilitating the reading thereof. These reference numbers should not be interpreted as limiting the claims in any form.