Refactoring (#1201)

* Some initial refactoring

* Make it one application

* Got it working

* Fix problem on Windows

* Move WebWolf

* Move first lesson

* Moved all lessons

* Fix pom.xml

* Fix tests

* Add option to initialize a lesson

This way we can create content for each user inside a lesson. The initialize method will be called when a new user is created or when a lesson reset happens

* Clean up pom.xml files

* Remove fetching labels based on language.

We only support English at the moment, all the lesson explanations are written in English which makes it very difficult to translate. If we only had labels it would make sense to support multiple languages

* Fix SonarLint issues

* And move it all to the main project

* Fix for documentation paths

* Fix pom warnings

* Remove PMD as it does not work

* Update release notes about refactoring

Update release notes about refactoring

Update release notes about refactoring

* Fix lesson template

* Update release notes

* Keep it in the same repo in Dockerhub

* Update documentation to show how the connection is obtained.

Resolves: #1180

* Rename all integration tests

* Remove command from Dockerfile

* Simplify GitHub actions

Currently, we use a separate actions for pull-requests and branch build.
This is now consolidated in one action.
The PR action triggers always, it now only trigger when the PR is
opened and not in draft.
Running all platforms on a branch build is a bit too much, it is better
 to only run all platforms when someone opens a PR.

* Remove duplicate entry from release notes

* Add explicit registry for base image

* Lesson scanner not working when fat jar

When running the fat jar we have to take into account we
are reading from the jar file and not the filesystem. In
this case you cannot use `getFile` for example.

* added info in README and fixed release docker

* changed base image and added ignore file

Co-authored-by: Zubcevic.com <rene@zubcevic.com>

src/main/resources/lessons/cryptography/documentation/Crypto_plan.adoc

@@ -0,0 +1,29 @@
+= Cryptography Basics 
+ 
+== Concept 
+
+This lesson explains different types of cryptography techniques that are commonly used in web applications. 
+
+== Goals
+
+The goal is to get familiar with the following forms of techniques:
+
+* link:start.mvc#lesson/Crypto.lesson/1[Encoding]
+
+* link:start.mvc#lesson/Crypto.lesson/3[Hashing]
+
+* link:start.mvc#lesson/Crypto.lesson/4[Encryption]
+
+* link:start.mvc#lesson/Crypto.lesson/5[Signing]
+
+* link:start.mvc#lesson/Crypto.lesson/6[Keystores]
+
+* link:start.mvc#lesson/Crypto.lesson/7[Security defaults]
+
+* link:start.mvc#lesson/Crypto.lesson/8[Post quantum crypto]
+
+=== Assignments
+
+After the explanation of an item there will be several assignments.
+
+

src/main/resources/lessons/cryptography/documentation/defaults.adoc

@@ -0,0 +1,33 @@
+= Security defaults 
+
+A big problem in all kinds of systems is the use of default configurations.
+E.g. default username/passwords in routers, default passwords for keystores, default unencrypted mode, etc.
+
+== Java cacerts
+
+Did you ever *_changeit_*? Putting a password on the cacerts file has some implications. It is important when the trusted certificate authorities need to be protected and an unknown self signed certificate authority cannot be added too easily.
+
+== Protecting your id_rsa private key
+
+Are you using an ssh key for GitHub and or other sites and are you leaving it unencrypted on your disk? Or even on your cloud drive? By default, the generation of an ssh key pair leaves the private key unencrypted. Which makes it easy to use and if stored in a place where only you can go, it offers sufficient protection. However, it is better to encrypt the key. When you want to use the key, you would have to provide the password again.
+
+== SSH username/password to your server
+
+When you are getting a virtual server from some hosting provider, there are usually a lot of not so secure defaults. One of which is that ssh to the server runs on the default port 22 and allows username/password attempts. One of the first things you should do, is to change the configuration that you cannot ssh as user root, and you cannot ssh using username/password, but only with a valid and strong ssh key. If not, then you will notice continuous brute force attempts to login to your server.
+
+ 
+== Assignment
+
+In this exercise you need to retrieve a secret that has accidentally been left inside a docker container image. With this secret, you can decrypt the following message: *U2FsdGVkX199jgh5oANElFdtCxIEvdEvciLi+v+5loE+VCuy6Ii0b+5byb5DXp32RPmT02Ek1pf55ctQN+DHbwCPiVRfFQamDmbHBUpD7as=*. 
+You can decrypt the message by logging in to the running container (docker exec ...) and getting access to the password file located in /root. Then use the openssl command inside the container (for portability issues in openssl on Windows/Mac/Linux)
+You can find the secret in the following docker image, which you can start as:
+
+	docker run -d webgoat/assignments:findthesecret
+
+[source]
+----
+echo "U2FsdGVkX199jgh5oANElFdtCxIEvdEvciLi+v+5loE+VCuy6Ii0b+5byb5DXp32RPmT02Ek1pf55ctQN+DHbwCPiVRfFQamDmbHBUpD7as=" | openssl enc -aes-256-cbc -d -a -kfile ....
+----
+
+
+

src/main/resources/lessons/cryptography/documentation/encoding_plan.adoc

@@ -0,0 +1,26 @@
+= Cryptography Basics 
+ 
+== Base64 Encoding 
+
+Encoding is not realy cryptography, but it is used a lot in all kinds of standards around cryptographic functions. Especially Base64 encoding. 
+
+Base64 encoding is a technique used to transform all kinds of bytes to a specific range of bytes. This specific range is the ASCII readable bytes.
+This way you can transfer binary data such as secret or private keys more easily. You could even print these out or write them down.
+Encoding is also reversible. So if you have the encoded version, you can create the original version.
+
+On wikipedia you can find more details. Basically it goes through all the bytes and transforms each set of 6 bits into a readable byte (8 bits). The result is that the size of the encoded bytes is increased with about 33%.
+
+	Hello ==> SGVsbG8=
+	0x4d 0x61 ==> TWE= 
+
+=== Basic Authentication
+
+Basic authentication is sometimes used by web applications. This uses base64 encoding. Therefore, it is important to at least use Transport Layer Security (TLS or more commonly known as https) to protect others from reading the username password that is sent to the server.
+
+	$echo -n "myuser:mypassword" | base64
+	bXl1c2VyOm15cGFzc3dvcmQ=
+	
+The HTTP header will look like:
+	
+	Authorization: Basic bXl1c2VyOm15cGFzc3dvcmQ=
+	

src/main/resources/lessons/cryptography/documentation/encoding_plan2.adoc

@@ -0,0 +1,25 @@
+= Cryptography Basics 
+ 
+== Other Encoding 
+
+Also other encodings are used. 
+
+=== URL encoding
+
+URL encoding is used a lot when sending form data and request parameters to the server. Since spaces are not allowed in a URL, this is then replaced by %20. Similar replacements are made for other characters.
+
+=== HTML encoding
+
+HTML encoding ensures that text is displayed as-is in the browser and not interpreted by the browser as HTML.
+
+=== UUEncode
+
+The Unix-2-Unix encoding has been used to send email attachments.
+
+=== XOR encoding
+
+Sometimes encoding is used as a first and simple obfuscation technique for storing passwords. IBM WebSphere Application Server e.g. uses a specific implementation of XOR encoding to store passwords in configuration files. IBM recommends to protect access to these files and to replace the default XOR encoding by your own custom encryption. However when these recommendations are not followed, these defaults can become a vulnerability.
+
+== Assignment
+
+Now let's see if you are able to find out the original password from this default XOR encoded string.

src/main/resources/lessons/cryptography/documentation/encryption.adoc

@@ -0,0 +1,32 @@
+= Encryption 
+ 
+== Symmetric encryption 
+
+Symmetric encryption is based on a shared secret that is used for both encryption as well as decryption. Therefore, both parties (that are involved in exchanging secrets) share the same key.
+
+Example protocols are:
+
+* AES
+* 3DES
+
+== Asymmetric encryption
+
+Asymmetric encryption is based on mathematical principles that consist of a key pair. The two keys are usually called a private key and a public key. The private key needs to be protected very well and is only known to one party. All others can freely use the public key. Something encrypted with the private key can be decrypted by all that have the public key, and something encrypted with the public key can only be decrypted with the private key.
+ 
+Example protocols are:
+
+* RSA
+* DSA
+
+== HTTPS uses both symmetric and asymmetric keys
+
+Here is a short description of what happens if you open your browser and go to an https site.
+
+* Your browser connects to the server and gets the webserver certificate
+* Your browser checks if it trusts the certificate issuer by checking if the issuer certificate is in its trust store. This trust store is managed by operating system and browser updates. And on some corporate networks it is managed by the company. From the certificate the browser obtains the public key.
+* The browser now generates random bytes to be used to generate a symmetric key and encrypts this with the public key of the server. So only the server can decrypt it.
+* At the end of this process both the browser and the webserver will use the exchanged symmetric key (in the asymmetric key exchange process) to encrypt and decrypt messages that are sent back and forth between the browser and the webserver.
+
+Symmetric keys are used because it can be used more easily with large sets of data and requires less processing power in doing so. However, the information on these pages is just for a basic understanding of cryptography. Look on the internet for more detailed information about these topics.
+
+

src/main/resources/lessons/cryptography/documentation/hashing_plan.adoc

@@ -0,0 +1,20 @@
+= Cryptography Basics 
+ 
+== Plain Hashing 
+
+Hashing is a type of cryptography which is mostly used to detect if the original data has been changed. A hash is generated from the original data. It is based on irreversible cryptographic techniques. 
+If the original data is changed by even one byte, the resulting hash is also different.
+
+So in a way it looks like a secure technique. However, it is NOT and even NEVER a good solution when using it for passwords. The problem here is that you can generate passwords from dictionaries and calculate all kinds of variants from these passwords. For each password you can calculate a hash. This can all be stored in large databases. So whenever you find a hash that could be a password, you just look up the hash in the database and find out the password.
+
+Some hashing algorithms should no longer be used: MD5, SHA-1
+For these hashes it is possible to change the payload in such a way that it still results in the same hash. This takes a lot of computing power, but is still a feasible option.
+
+== Salted Hashes
+
+Plain passwords should obviously not be stored in a database. And the same goes for plain hashes.
+The https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html[OWASP Password Storage Cheat Sheet,window=_blank] explains what should be used when password related information needs to be stored securely.
+
+== Assignment
+
+Now let's see if you can find what passwords matches which plain (unsalted) hashes.

src/main/resources/lessons/cryptography/documentation/keystores.adoc

@@ -0,0 +1,35 @@
+= Keystores & Truststores
+
+A keystore is a place where you store keys. Besides *_keystore_* the term *_truststore_* is also used frequently. A truststore is the same thing as a keystore. Only it usually contains only the certificates (so basically only public keys and issuer information) of trusted certificates or certificate authorities. 
+ 
+== File based keystores 
+
+A file based keystore is something that in the end has the keys on a file system.
+Storing public certificates in a file based keystore is very common
+
+== Database keystores
+
+Keys and especially public certificates can of course also be stored in a database. 
+
+== Hardware keystore
+
+A hardware keystore is a system that has some sort of hardware which contain the actual keys.
+This is typically done in high end security environments where the private key is really private.
+In comparison with file based or database keystores, it is impossible to make a copy of the keystore to send it to some unknown and untrusted environment. 
+
+Some certificate authorities that are used to provide you with a server certificate for your website, also create the private keys for you (as-a-service). However, it is by definition no longer considered a private key. For all keystore types, you should keep the private key private and use a certificate signing request to order your signing or server certificates.
+
+== Managed keystores in operating system, browser and other applications
+
+When you visit a website and your browser says that the certificates are fine, it means that the certificate used for the website is issued by a trusted certificate authority. But this list of trusted certificate authorites is managed. Some CA's might be revoked or removed. These updates happen in the background when browser updates are installed. 
+Not only the browser maitains a list of trusted certificate authorities, the operation system does so as well. And the Java runtime also has its own list which is kept in the cacerts file. Updates of the OS and Java JRE keep this list up to date. In coporate environments, these are usually maintained by the company and also contain company root certificates.
+
+== Extra check for website certificates using DNS CAA records
+
+Some companies inspect all or most internet traffic. Even the ones were you think you have an end-2-end secured connection. This works as follows. An employee opens a browser and googles some information. The browser will use https and go to the site of google. The link looks real and the lock is shown in the browser. However, if you would inspect the certificate, you might notice that it has been issued by one of your companies root CA's! So you have established an end-2-end secure connection with a server of your company, and that server has the secure connection with google. 
+In order to prevent such man in the middle connections to your server, modern browsers now will also check the DNS CAA records to see whether or not a certain issuer is allowed for a certain website.
+More information: https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization[Wiki DNS CAA,window=_blank] 
+
+== Free certificates from Let's encrypt
+
+https://letsencrypt.org[Let's encrypt,,window=_blank] is a free, automated and open Certificate Authority. It allows you to create valid certificates for the websites that you control. By following and implementing a certain protocol, your identity is checked and a certificate will be issued. The certificates are free of charge and this is done to stimulate the use of authorised certificates and to lower the use of self-signed certificates on the internet. Certificates are valid for 90 days, so they need to be automatically renewed. (Which makes sure that the proof of identity/ownership also takes place frequently)

src/main/resources/lessons/cryptography/documentation/postquantum.adoc

@@ -0,0 +1,7 @@
+= Post Quantum
+
+== Post quantum cryptography
+
+Quantum computers are here and getting more power in available qubits each year. Quantum computers are and will be capable of decrypting information that was encrypted with algorithms that were thought to be safe. For some years now, a lot of encrypted communicatation using quantum vulnerable cryptoraphy is being recorded. This information will be decrypted when the quantum computers are powerful enough. Even though the information may be old, it still could contain valuable information that can be misused. Besides the fact that some private information will be known to parties it was not intended for.
+
+Mathematics has answers for the post quantum era. New cryptography is already available and should be used NOW in order to minimize threats. You can read more on this on Wikipedia: https://en.wikipedia.org/wiki/Post-quantum_cryptography[Post quatum on Wikipedia,window=_blank]

src/main/resources/lessons/cryptography/documentation/signing.adoc

@@ -0,0 +1,40 @@
+= Signing 
+
+A signature is a hash that can be used to check the validity of some data. The signature can be supplied separately from the data that it validates, or in the case of CMS or SOAP can be included in the same file. (Where parts of that file contain the data and parts contain the signature).
+
+Signing is used when integrity is important. It is meant to be a guarantee that data sent from Party-A to Party-B was not altered. So Party-A signs the data by calculating the hash of the data and encrypting that hash using an asymmetric private key. Party-B can then verify the data by calculating the hash of the data and decrypting the signature to compare if both hashes are the same.
+ 
+== RAW signatures 
+
+A raw signature is usually calculated by Party-A as follows: 
+
+* create a hash of the data (e.g. SHA-256 hash)
+* encrypt the hash using an asymmetric private key (e.g. RSA 2048 bit key)
+* (optionally) encode the binary encrypted hash using base64 encoding
+
+Party-B will have to get the certificate with the public key as well. This might have been exchanged before. So at least 3 files are involved: the data, the signature and the certificate.
+
+== CMS signatures
+
+A CMS signature is a standardized way to send data + signature + certificate with the public key all in one file from Party-A to Party-B. As long as the certificate is valid and not revoked, Party-B can use the supplied public key to verify the signature.
+
+== SOAP signatures
+
+A SOAP signature also contains data and the signature and optionally the certificate. All in one XML payload. There are special steps involved in calculating the hash of the data. This has to do with the fact that the SOAP XML sent from system to system might introduce extra elements or timestamps. 
+Also, SOAP Signing offers the possibility to sign different parts of the message by different parties.
+
+
+== Email signatures
+
+Sending emails is not very difficult. You have to fill in some data and send it to a server that forwards it, and eventually it will end up at its destination. However, it is possible to send emails with a FROM field that is not your own email address. In order to guarantee to your receiver that you really sent this email, you can sign your email. A trusted third party will check your identity and issue an email signing certificate. You install the private key in your email application and configure it to sign emails that you send out. The certificate is issued on a specific email address and all others that receive this email will see an indication that the sender is verified, because their tools will verify the signature using the public certificate that was issued by the trusted third party.
+
+== PDF or Word or other signatures
+
+Adobe PDF documents and Microsoft Word documents are also examples of things that support signing. The signature is also inside the same document as the data so there is some description on what is part of the data and what is part of the metadata.
+Governments usually send official documents with a PDF that contains a certificate.
+
+== Assignment
+
+Here is a simple assignment. A private RSA key is sent to you. Determine the modulus of the RSA key as a hex string, and calculate a signature for that hex string using the key. The exercise requires some experience with OpenSSL. You can search on the Internet for useful commands and/or use the HINTS button to get some tips.
+
+

src/main/resources/lessons/cryptography/html/Cryptography.html

@@ -0,0 +1,129 @@
+<!DOCTYPE html>
+
+<html xmlns:th="http://www.thymeleaf.org">
+<header>
+<script>
+/**
+ * JavaScript to load initial assignment tokens 
+ */
+function initialise() {
+	$("#sha256token").load('/WebGoat/crypto/hashing/sha256');
+	$("#md5token").load('/WebGoat/crypto/hashing/md5');
+	$("#basicauthtoken").load('/WebGoat/crypto/encoding/basic');
+	$("#privatekey").load('/WebGoat/crypto/signing/getprivate');
+}
+$(document).ready(initialise);
+</script>
+</header>
+<body>
+	<!-- 1. overview -->
+	<div class="lesson-page-wrapper">
+		<div class="adoc-content" th:replace="doc:lessons/cryptography/documentation/Crypto_plan.adoc"></div>
+	</div>
+	<!-- 2. encoding -->
+	<div class="lesson-page-wrapper">
+		<div class="adoc-content" th:replace="doc:lessons/cryptography/documentation/encoding_plan.adoc"></div>
+		<!-- 2. assignment -->
+		<div class="attack-container">
+			<div class="assignment-success"><i class="fa fa-2 fa-check hidden" aria-hidden="true"></i></div>
+			Now suppose you have intercepted the following header:<br/>
+			<div id="basicauthtoken" ></div><br/>
+			<form class="attack-form" method="POST" name="form"	action="/WebGoat/crypto/encoding/basic-auth">
+			Then what was the username 
+			<input name="answer_user" value="" type="TEXT"/>
+			and what was the password: 
+			<input name="answer_pwd" value="" type="TEXT"/>
+			<input name="SUBMIT" value="post the answer" type="SUBMIT"/>
+			</form>
+			<div class="attack-feedback"></div>
+			<div class="attack-output"></div>
+		</div>		
+	</div>
+	<!-- 3. encoding xor -->
+	<div class="lesson-page-wrapper">
+		<div class="adoc-content" th:replace="doc:lessons/cryptography/documentation/encoding_plan2.adoc"></div>
+		<!-- 3. assignment xor -->
+		<div class="attack-container">
+			<div class="assignment-success"><i class="fa fa-2 fa-check hidden" aria-hidden="true"></i></div>
+			<form class="attack-form" method="POST" name="form"	action="/WebGoat/crypto/encoding/xor">
+			Suppose you found the database password encoded as {xor}Oz4rPj0+LDovPiwsKDAtOw==<br/>
+			What would be the actual password
+			<input name="answer_pwd1" value="" type="TEXT"/><br/>
+			<input name="SUBMIT" value="post the answer" type="SUBMIT"/>
+			</form>
+			<div class="attack-feedback"></div>
+			<div class="attack-output"></div>
+		</div>
+	</div>
+
+	<!-- 4. hashing -->
+	<div class="lesson-page-wrapper">
+		<div class="adoc-content" th:replace="doc:lessons/cryptography/documentation/hashing_plan.adoc"></div>
+		<!-- 4. weak hashing exercise -->
+		<div class="attack-container">
+			<div class="assignment-success"><i class="fa fa-2 fa-check hidden" aria-hidden="true"></i></div>
+			<form class="attack-form" method="POST" name="form"	action="/WebGoat/crypto/hashing">
+			Which password belongs to this hash: <div id="md5token" ></div>
+			<input name="answer_pwd1" value="" type="TEXT"/><br/>
+			Which password belongs to this hash: <div id="sha256token" ></div>
+			<input name="answer_pwd2" value="" type="TEXT"/>
+			<input name="SUBMIT" value="post the answer" type="SUBMIT"/>
+			</form>
+			<div class="attack-feedback"></div>
+			<div class="attack-output"></div>
+		</div>		
+	</div>
+	
+	<!-- 5. encryption -->
+	<div class="lesson-page-wrapper">
+		<div class="adoc-content" th:replace="doc:lessons/cryptography/documentation/encryption.adoc"></div>
+	</div>
+
+	<!-- 6. signing -->
+	<div class="lesson-page-wrapper">
+		<div class="adoc-content" th:replace="doc:lessons/cryptography/documentation/signing.adoc"></div>
+		<!-- 6. assignment -->
+		<div class="attack-container">
+			<div class="assignment-success"><i class="fa fa-2 fa-check hidden" aria-hidden="true"></i></div>
+			Now suppose you have the following private key:<br/>
+			<pre><div id="privatekey" ></div></pre><br/>
+			<form class="attack-form" method="POST" name="form"	action="/WebGoat/crypto/signing/verify">
+			Then what was the modulus of the public key 
+			<input name="modulus" value="" type="TEXT"/>
+			and now provide a signature for us based on that modulus 
+			<input name="signature" value="" type="TEXT"/>
+			<input name="SUBMIT" value="post the answer" type="SUBMIT"/>
+			</form>
+			<div class="attack-feedback"></div>
+			<div class="attack-output"></div>
+		</div>
+	</div>
+	
+	<!-- 7. keystores -->
+	<div class="lesson-page-wrapper">
+		<div class="adoc-content" th:replace="doc:lessons/cryptography/documentation/keystores.adoc"></div>
+	</div>
+	
+	<!-- 8. security defaults -->
+	<div class="lesson-page-wrapper">
+		<div class="adoc-content" th:replace="doc:lessons/cryptography/documentation/defaults.adoc"></div>
+		<!-- 8. assignment -->
+		<div class="attack-container">
+			<div class="assignment-success"><i class="fa fa-2 fa-check hidden" aria-hidden="true"></i></div>
+			<form class="attack-form" method="POST" name="form"	action="/WebGoat/crypto/secure/defaults">
+			What is the unencrypted message<br/>
+			<input name="secretText" value="" type="TEXT"/><br/>
+			and what is the name of the file that stored the password <br/>
+			<input name="secretFileName" value="" type="TEXT"/>
+			<input name="SUBMIT" value="post the answer" type="SUBMIT"/>
+			</form>
+			<div class="attack-feedback"></div>
+			<div class="attack-output"></div>
+		</div>
+	</div>
+	<!-- 9. postquantum -->
+	<div class="lesson-page-wrapper">
+		<div class="adoc-content" th:replace="doc:lessons/cryptography/documentation/postquantum.adoc"></div>
+	</div>
+</body>
+</html>

src/main/resources/lessons/cryptography/i18n/WebGoatLabels.properties

@@ -0,0 +1,32 @@
+6.crypto.title=Crypto Basics
+
+crypto-encoding.empty=Try again, did you decode it properly?
+crypto-encoding.success=Congratulations. That was easy, right?
+
+crypto-hashing.empty=Try again.
+crypto-hashing.oneok=Try again. You got 1 right.
+crypto-hashing.success=Congratulations. You found it!
+
+crypto-hashing.hints.1=Guess the type of hashing from the length of the hash.
+crypto-hashing.hints.2=Find a online hash database or just google on the hash itself.
+
+crypto-signing.hints.1=Use openssl to get the public key from the private key. Apparently both private and public key information are stored.
+crypto-signing.hints.2=Use the private key to sign the "modulus" value of the public key.
+crypto-signing.hints.3=Actually the "modulus" of the public key is the same as the private key. You could use openssl rsa -in test.key -pubout > test.pub and then openssl rsa -in test.pub -pubin -modulus -noout or other components. 
+crypto-signing.hints.4=Make sure that you do not take hidden characters into account. You might want to use echo -n "00AE89..." | openssl dgst -sign somekey -sha256 ... and do not forget to base64 encode the outcome
+ 
+
+crypto-signing.notok=The signature does not match the data (modulus)
+crypto-signing.modulusnotok=The modulus is not correct
+crypto-signing.success=Congratulations. You found it!
+
+crypto-encoding-xor.empty=Try again. This is not right
+crypto-encoding-xor.success=Congratulations.
+crypto-encoding-xor.hints.1=Did you look for online decoders for WebSphere encoded password?
+
+crypto-secure-defaults.hints.1=After starting the docker container enter the container using docker exec -ti _dockerid_ /bin/bash
+crypto-secure-defaults.hints.2=Try to gain access to /root. Try to become user root by su -
+crypto-secure-defaults.hints.3=Try to change the /etc/shadow file using docker cp
+crypto-secure-defaults.success=Congratulations, you did it!
+crypto-secure-defaults.messagenotok=The unencrypted message is not correct, try again. The filename of the password file is correct.
+crypto-secure-defaults.notok=Try again or read some of the hints.