Email spam targeted at a pair of users Two users on my domain are receiving spam emails that have both of their emails in either the To: and/or CC: fields. There are many other users on the domain, but only these two are receiving spam emails. The two accounts are not exclusively linked or associated (eg. only two of them belonging in the same group)

Over the last few days, both have received hundreds of messages (the same messages essentially). There is a spam filter on the mail server in place but its the fact that they're both getting the same spam messages that I'm wondering about.

The headers indicate that they're coming from spam servers all over the world. Each email is different (sample copied below, replaced private information with mail.mydomain.com etc.)

Received: from max (5.178.191.234) by --mail.mydomain.com--
 (X.X.X.X) with Microsoft SMTP Server id X.X.X.X; Fri, 27 Sep 2013
 04:48:43 -0700
Received: (from root@localhost) by mail0.wiktionary.org (8.11.3/8.11.3) id
 k8V5OhN08473; Fri, 27 Sep 2013 11:48:43 -0300 (PDT envelope-from root)
Date: Fri, 27 Sep 2013 10:55:07 -0300
Message-ID: <80252799905272.ZBiaUKfUeG@smithereens>
X-Mailer: phpmailer [version 1.41]
X-BeenThere: taxied@mailman.wiktionary.org
X-Kaspersky: Checking
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
To: <--usera@mydomain.com-->, <--user_b@mydomain.com-->
From: Get BIGGER with Free trial <precambrianclapeyron@wiktionary.org>
Subject: Disappointed at your lack of performance?
MIME-Version: 1.0
Return-Path: precambrianclapeyron@wiktionary.org
X-MS-Exchange-Organization-AuthSource: --mail.mydomain.com--
X-MS-Exchange-Organization-AuthAs: Anonymous

My question is what is the most reasonable explanation for both users to be in the To: and CC: fields of spam?

At first, I thought domain attack, but then why only two users?
Or if it is a single user being compromised, then why is it only spamming one other user when it has a whole address book?
Another idea is that this is a targeted attack against the two, but is that possible? Is there some spam machine that someone could dunk two names into and be put on a list to be spammed together? I could understand both being on the same list and spamming individually, but together? It seems incredibly bizarre.

A plausible hypothesis is the following:

The spammer optimizes his spam-sending by grouping targets from the same domain: when a spam must be sent to userA@example.com, userB@example.com and userC@example.com, then the spam software sends a single email to the incoming SMTP server of example.com, with the three addresses as recipients. Email grouping is good for bandwidth, and this benefits the spammer as well.
The spam themselves are sent through a botnet, so they seem to come from "the whole planet" with no single source.
The spammer has collected a lot of addresses, including the addresses of these two users, but none other. Why ? Because neither of the two users got his machine compromised in any way. It is someone else, completely outside of your organization, who installed malware on his machine; and that third person, that you don't know and over which you have no control, had the two users' email addresses in his address book.

It is an unfortunate property of spamming that you get spammed because of the sloppy behaviour of other people.

Don't forget, too, that spammers are not necessarily good at what they do. I regularly receive weird spams: empty messages, spams whose text contents is "%INSERT_RANDOM_CONTENT", hundreds of copies of a single spam... A lot of wannabe spammers appear to have difficulty using their own spamming tools. As usual, incompetence is a driving force of the Universe and explains a lot of the observed weirdness.


What phases does a network penetration test consist of? What are common phases of a network infrastructure penetration test?

Staring with discovering IP's and ports? A simple vulnerability assessment, checking version information of banners from different services on different ports against CVE(-like) databases? Checking availability from outside the network? Start to monitor the network traffic for some time using sniffing?

With the purpose to get an overview of possible security issues and vulnerabilities regarding the network infrastructure and configuration.

When I engage in penetration testing, my goals go above beyond finding open ports, to finding "information" that could be used to gain access, or negatively impact the company. If you solely focus on ports (services), or CVE information, you will likely miss common indicators, and information that an attacker will not miss. Usually my penetration tests, begin as vulnerability assessments:

NMAP / Unicorn Scan (network mapping tools)
Nessus / OpenVAS (vulnerability scanners)
Separate laptop running Wireshark + SpiderLabs' Responder

Network mapping may paint a decent picture, but an off the shelf NMAP scan will not yield as much information as say a Nessus/OpenVAS scan, that can show open shares. A typical first day may include nothing more than discovery (arp scans, nmap scans, vulnerability scanning) so that I can create an attack surface.

Once an attack surface is built, work splits into automation, and manual checking. I will never run an exploits against a vulnerability, where that exploit may trigger a denial of service. Defeats the purpose, whereas I can document: "exploits are available, however they were not run due to a Denial of Service" I make this understood to client: "Door is open, attacker will come in, we didn't because we would cause chaos."

For services, I take HTTP+HTTPS servers and send them off to be tested using Nikto, Wikto, Burpsuite, and AppScan. Rinse and review, wait for output, analyze data, and go from there. For services on specific devices (e.g. SSH on a Cisco switch), I will attempt a brute force for top 50 passwords ONLY. There is a reason for this: I need to check whether I have access to ATTEMPT to make a change, and whether I (as an attacker) I will be blocked after N attempts. There is no need for me to go further than the top ten, as I can word it properly: "Attacker has the capability to repeatedly bruteforce the device unchecked. Due to the amount of time in this engagement, we checked 50 top passwords..." Again, makes no sense to attack with say RockYou password list. The reality is, given enough time an attacker may bruteforce the password... They are not being blocked from attempting it.

Information is king. For example, on many Nessus scans, I always look at the informational data. Often I find I will see something like "NFS Share World Readable" to where I can remove myself from a domain, mount a share, and lo and behold, many times I have obtained access to PST files, company confidential material. What do you think is more business critical, telling a client: "I zero day'd your SRX gateway (that you can't fix, but will have to rely on a vendor) versus: I was able to mount 10.10.10.2:/backups/CEO/backup.pst"

I disagree with the banner checking comment in the above, as organizations under some mandates are supposed to create their own banners: "Restricted use anyone will be prosecuted" not to mention it is easy for NMAP to throw out a lot of false positives. For fingerprinting, I will rely on p0f.

I often look for internal relays, as it is easier to bypass spam filters, and may send an employee a phishing email in order to test multiple things: 1) Employee awareness (did they open the email) 2) Technological mitigations (spam filters) 3) Patch management (if my attachment has client sides against IE8.0 were they triggered).

I suggest looking at Penetration Testing Execution Standard for more information that will help you with your question. There will be multiple answers to this question, but there is also using experience to begin chaining attacks. E.g. so you found a null share against a Windows machine. Take the output and build a list of users (since some null scans will get this for you), build a list of networks you didn't know about (obtained from say a public snmpwalk), chain these together with a 50 top password bruteforce against say a printer, share, etc.

---- (Added)

Also take note, prior to running any tool, if you can plug into a network and see traffic, that itself is a finding (there is no Network Access Control). If you can run Wireshark and Responder, more findings. There is a lot to do outside of firing off nmap, Nessus, Metasploit, etc. Information should be analyzed as best as possible, and with that said, experience is the biggest tool you will have in your arsenal


Distance between main site and Disaster recovery site i couldn't find any specific requirements for distance between main site and DR at the regulations or best practices only descriptions as “safe distance”
can any one provide reference to something some specific ?

It depends on the geographic scope of the threat that you are trying to mitigate balanced with the costs and impact of distance on operations and recovery.

If the main site is in a drought-prone wooded forest with dry grasslands, you'd want your DR site beyond the fire zone. If the main site is in an earthquake zone, you'd want your DR outside of that zone. If the main site is in an area where the infrastructure itself is a risk (unstable governments, unreliable communication lines, etc.) you would want the DR site in an area with different infrastructure. And so on.

But distance incurs cost and impact. To place your DR site on the other side of the planet means that you are maximally separated from any geographic zones the main site might be exposed to, but in a disaster, it is maximally difficult to get to the DR site. Distance, itself, becomes a risk factor to consider and weigh against the risks calculated for the main site.

So, I doubt you would find any regulations regarding a "safe distance" because it is a function of the geographic risks, risks incurred by increased distance, and costs and availability of a DR site in a particular location.

Always remember, mitigations always introduce their own, new risks to weigh. Costs and risks of mitigations must not exceed the impacts of the main risk subject.


What other attacks can be deployed using IP spoofing other than DoS(and DDoS) attacks ? I want to know the other attacks which are associated with IP spoofing because, we're trying to implement Source Address Validation (SAVA) and wanted to where else can Source Address validation techniques can be used?
This is for a Project purpose and any recent references/suggestions will be very helpful.

The two major attack vectors that spring to mind are Non-Blind and Blind spoofing, which make use of spoofed IP's and TCP to take control of a IP/TCP session. Although the Non-Blind attack in particular may not be prevented by Source address validation.

When on the same subnet as an attacker, hijacking of a legitimate TCP connection is possible by sniffing the sequence and acknowledgement numbers of the TCP segments. By spoofing the target IP and corrupting the data stream, the session can be re-established by the attacker with the spoofed IP and sniffed the seq and ack numbers, thus hijacking the session. This is known as Non-Blind Spoofing

There is also an attack known as Blind Spoofing that is more sophisticated an only likely to be possible on legacy systems. This attack can be used when the sequence and acknowledgement numbers are unreachable by the attacker. By sampling packets sent to the target an attacker could predict the acknowledgement and sequence numbers, and thus hijack the TCP session. Modern implementations of the TCP protocol however use random sequence number generators making this attack vector unlikely to succeed.


Using SSH Private keys in Production environment I have a need to scp a bunch of files from a production box to my development environment.  I am a developer and have limited read access to the production machines. Instead of entering password for each file, I wanted to create a keypair in production and store the public key in authorized_keys on my dev machine.

The key is for my LDAP login to production.  Is this safe?  Can something go wrong here?  Thanks.

The production machines are not web facing. The machines are in the company data-centers and are "supposed to be" only accessible from within the corporate network.

If you're doing this to avoid entering passwords, then that implies that either you'll run an SSH agent on Production, or you'll keep an unencrypted private key there.  If it's the latter, then the administrators of Production will have access to your development box.

But if I'm reading between the lines correctly, you're using this approach as a workaround because you can't add your dev key to authorized_keys on Production.  In that case, there's a better way to get what you want.

If you're using OpenSSH, you can avoid entering the password multiple times even with password-based access, by using SSH connection sharing.  Once you've configured this, you SSH into the server normally in one window, typing in your password as normal.  In another window, you do your copying, and your SCP client finds and uses the existing connection with no password entry required.

To set this up:

$ mkdir ~/.ssh/cm_socket

And add the following to your ~/.ssh/config:

ControlMaster auto
ControlPath ~/.ssh/cm_socket/%C
ControlPersist no

After this, SSH and SCP will look for a shared connection by default.  If you want to make a second, non-shared connection for some reason, you can add -S none to your command line.

For more info:

man ssh_config and look for ControlMaster, ControlPath, and ControlPersist
https://stackoverflow.com/q/20410252/460258
https://puppetlabs.com/blog/speed-up-ssh-by-reusing-connections


Phishing email repository for analysis Is there a repository of known phishing emails somewhere that is available for analysis purposes? I want to test some mitigation theories and need a good collection of data to test against.

There is at least a quite good collection of spam mails as such available at http://artinvoice.hu/spams/. I would consider phishing mails as a a subcategory of spam and expect you to also find phishing mails in that body.


Office password protection crack would just like to have a check on the password protection/encryption of MS office 2007 and above. It is said that its not that easy to crack the password protection except by brute force, since 2007 and above version of office use AES128bit encryption. Is this true till now, as in have you come across any cracking tools that is able to crack 2007 and above password protections?
thanks

Elcomsoft Advanced Office Password Recovery may be what you're looking for; you'll need at least the Standard edition for GPU acceleration, and the Professional edition if you have more than one GPU or you want certain other features.

John the Ripper Community-Enhanced (Jumbo) also has this capability.

Note that brute force is a poor cracking method once passwords reach reasonable lengths; mask attacks and rules-based dictionary attacks are much more efficient at many passwords humans choose.


Are Extended Validation certificates any more secure than regular ones? Or are they just an attempt to get you to pay more money to a CA because it tells your browser to show the address bar in green with your organization's name?

Also, what are the technical details of EV certificates? What exactly makes a certificate contain EV in the certificate's details?

That EV certificates are "more secure" is definitely the message that the EV-Qualified CA are trying to assert -- this is how they justify that the EV certificates have higher prices. Whether EV certificates really improve the security situation is debatable. See for instance this criticism from Peter Gutmann (quoted on the Wikipedia page):

The introduction ... of so-called high-assurance or extended validation (EV) certificates that allow CAs to charge more for them than standard ones, is simply a case of rounding up twice the usual number of suspects - presumably somebody’s going to be impressed by it, but the effect on phishing is minimal since it’s not fixing any problem that the phishers are exploiting. Indeed, cynics would say that this was exactly the problem that certificates and CAs were supposed to solve in the first place, and that “high-assurance” certificates are just a way of charging a second time for an existing service. A few years ago certificates still cost several hundred dollars, but now that the shifting baseline of certificate prices and quality has moved to the point where you can get them for $9.95 (or even for nothing at all) the big commercial CAs have had to reinvent themselves by defining a new standard and convincing the market to go back to the prices paid in the good old days.
This deja-vu-all-over-again approach can be seen by examining Verisign’s certificate practice statement (CPS), the document that governs its certificate issuance. The security requirements in the EV-certificate 2008 CPS are (except for minor differences in the legalese used to express them) practically identical to the requirements for Class 3 certificates listed in Verisign’s version 1.0 CPS from 1996. EV certificates simply roll back the clock to the approach that had already failed the first time it was tried in 1996, resetting the shifting baseline and charging 1996 prices as a side-effect. There have even been proposals for a kind of sliding window approach to certificate value in which, as the inevitable race to the bottom cheapens the effective value of established classes of certificates, they’re regarded as less and less effective by the software that uses them...

The theory is that EV certificates are issued only after more thorough verification of the requester identity, so EV certificates should be safer in the following sense: it is harder to get a fake one. On the other hand, it seems that existing attackers don't really bother obtaining fake SSL certificates anyway, so the increase in safety is, indeed, theoretical.
In practice, the need for an EV certificate (as opposed to a non-EV certificate) for your server does not come from a real need for security, but from a real need for a green bar. It is all about convincing customers that spending their money on your site is "safe".


Defense of a server against malicious uploaded resources We know that viruses and other threats can propagate through mail etc.But when any resource is shared,it is uploaded to the server and then shared.This means that the server does not take the responsibility of cleaning the uploaded files of viruses.Then how does it ensure self defense and secure the resources present on it and various services running on it?

The server should do validation on the user submitted file. E.g. If you allow the user to upload an image file for their profile picture, you should make sure that the file is a JPEG or PNG file and not an EXE file.

More info : http://www.waytocode.com/2012/file-uploading-validation-in-php/

If you are running a file sharing service and allow all types of files to be uploaded.
Even if a malicious file to be uploaded, it will not infect your system as long as you do not execute it. For added security, set the executable flag to be off so that it cannot be executed through any means.


Is there any known Malware for Windows Phone 7? I cannot find anything on google that indicates there has been cases of malware on Windows Phone 7, doe's anyone know if this is true?

It appears Flame can hit Windows Phone 7 as Microsoft just released a patch to address an attack via the Microsoft update vector using the cert flaw (Information Week article of 5 June 2012). So that answer is yes there is malware that attacks Windows Phone 7.


Recommended policy on password complexity Is there any research on how how a password complexity policy can increase or decrease the quality of passwords?

If you don't have any requirements on the password then probably 90% of users will use their name or something just as insecure, but they will not be as prone to forget their password.

But on the other hand if you have to have a password with upper and lowercase characters, numbers and special characters like ! % €, that increases the problems (and associated support costs) of users forgetting their password.

So is the any documentation on how to create a password policy that helps the user create passwords they can remember but still have sufficient complexity to them?

Some links and recent research related to policies and the actual resistance to cracking of the resulting passwords is presented by Matt Weir in Reusable Security: New Paper on Password Security Metrics and CCS Paper Part #2: Password Entropy

One quick takeaway is noted: "forcing users to change their password every six months isn't very useful"

See also other questions here like this one.


What can a hacker do to my home router if I have the admin page enabled externally? Say my home router uses an OpenSSL version that is vulnerable to Heartbleed and I have the admin page enabled and accessible from the outside (even though I never use it).

What can a hacker do?

Could he for example read any traffic on my router or could he maybe get access to the admin page?

As I understand now, it can only read memory from the same process, so as long as I don't log in myself, there is not much interesting data there. However, from this answer I understand that there seems to be something with mmap that might make it possible to read memory from a different process.

Quoting the quote from that answer:

  However, if mmap is used, all bets are off. Any memory not in use could be allocated for mmap. This is what the most of the attacks against Heartbleed will target.

EDIT:
This question asks about specific routers, their software version and which ones would need patching. The answers there are very different from what I'm looking for here. Also the answers here are not really applicable for that question. I actually read that question and the answers before posting this question and at that time didn't even feel like it was similar enough that I had to mention it in my question.

The difference lies in the fact that this question more addresses what the specific risk is to ordinary people with home routers while the other question is more focussed on which routers are vulnerable and how to patch them.

Hence I don't think this should be marked as duplicate.

A lot of things, actually, depending on your router model. He could:

Dump all your traffic and read the unencrypted sessions...
...and try to attack the encrypted ones with tools such as sslstrip
Perform Man in the Middle attacks to modify the pages you are viewing, possibly to add browser exploits
Use the router as a relay to attack the rest of your home network
Worst case scenario, he may also be able to flash your router's firmware

So basically, don't have an internet facing router administration page.


Handwriting/cursive education is on the decline. How does this affect signature-based authentication? More and more schools are not teaching cursive handwriting, and many are considering it more of an art, or optional in the curriculum.

I assume this will have an impact on the ability to forge a person's signature.

However, I don't assume that an education (or lack thereof) in cursive affects the difficulty in forging a signature on demand.  That's what this question is about.

Question

Does the lack of (or excessive amounts of) handwriting training positively or negatively affect the ability to forge that individuals' signature?

Driving need

I am trying to access how much of digital or iPad based signatures are  security theater, or if there is some genuine value here.

I am very skilled in cursive handwriting, and I can tell you that such skill has little to no effect in forging another person's signature. Most often, people forget how cursive really works and just memorize a fast signature. This makes scrawled messes like you can usually find on a doctor's note common, and any real ability in cursive only makes you more aware of how much of a monstrosity it is. While cursive may make your hand steadier, forging a signature requires skill in the area of being able to draw and copy very well, not the skill of cursive. Of course, if you're interested in getting a perfect forgery it is much easier to use conveniences of the age such as cameras.

As for how it relates to information security, a signature is another imperfect verification process meant to slow scammers. It is possible to forge a signature, either with a skilled hand or with digital tools. However, if some scammer makes a fake card with your credentials, they likely will not know or care what your signature is. When you detect the malicious activity on your account, it is easy for the bank to check your signatures to find the fake ones. Your signature will also be checked on any large check. However, when you're buying five dollars worth of groceries it will likely be stored for a little while and never seen again. Any real understanding of cursive is pretty meaningless to this process.


Does data inside a VPC needs to be encrypted in trasit too? I know there are laws which require all data to be encrypted in transit and at rest. It makes sense for browser to server connections but,

Does data flow within a VPC, lets say a kubernetes cluster needs to be encrypted too?
Does the data in transit between RAM and mounted volumes needs to be encrypted too?
If I am not encrypting the data in RAM, is that violating some laws?

In general, you use a protection mechanism when there is a threat that you want to counter. So, if there is a threat within a cluster or between RAM and mounted volumes, then, yes, you should consider encryption.


What are the risks of using a self-signed SSL certificate over the internet for a b2b connection compared to using a CA cert? I would like to know about the additional security risks that are introduced by using a self-signed certificate versus using a CA signed certificate for a b2b connection over the internet. In this particular case, the connection is using mutual SSL with white-listed firewalls on both sides.

My understanding is that there are no risks compared to using a CA signed certificate if the client trusts me and adds my self-signed certificate to their trust store.

Thanks!

In your scenario most risks are associated with certificate management, because self-signed certificate offers zero manageability. For instance, certificate replacement, update, revocation. The lack of manageability leads to increased security risks.

For example, you use self-signed certificates for b2b communications. Internet-connected endpoints are more vulnerable to different attacks and there is quite big chance that the certificate/key is leaked/compromised. This can be a vulnerability in web app software, web server, OS, etc..

In order to replace the certificate, you will have to inform your partners about the incident, ask them to remove old certificate and install new self-signed certificate to their trust store. This process is very slow and during this timespan your partners will trust your compromised certificate, because of this delay.

When deploying standard PKI solution, it is easier to provide root certificate's adequate security level, because attack surface is very tiny. CA is not connected directly to internet and has very limited access within private network. In this case, root CA compromise is very unlikely. And if your web server got compromised (you can't afford the same security level like in CA server) you just revoke the certificate and replace the certificate on web server on a fly. And partners won't experience security or outage issues.


Store Hash and/or Encryption salts in database I am doing a custom login for practice purposes, and i am wondering what would be the logical way to save the hashed password and the salts.

Salt/Hash operations are using Rfc2898DeriveBytes class.

As for now, it is like this:

The user registers, the password is encrypted with a random salt (which is saved to the database) and hashed with a hard-coded salt with 10000 iterations.

As the iterations can be raised in time due to computational improvements, i am saving the Hash iterations (the Encryption iterations are hard-coded) them on the database.

I would like opinions on how safe is a hard-coded hash salt, or if i should make it random and add the hash salt to the database too.

I would recommend you use a static string as a salt for example,  "thisisstaticand10000characterslong". Use the password inside this ( $salt1.$post['password'].$salt2).  Then hash it with MD5. If the user wants to login than you make the same method to check if the password entered by the user is correct.

if(md5(($salt1.$_POST['password'].$salt2) == $password)
{
    /* Your code */
}


InfoSec certifications for global startup I am working in a global startup. Recently we have undergone several InfoSec processes with potential large corporate customers.

All of them asked for:

SOC
ISO 27k

Which makes sense for large organizations.

What certificates are worth pursuing in terms of Privacy/Security for a smaller startup?

Thought about:

UKs Cybers Essentials Plus
EuroPrise
German BSI Grundschutz

Since we are a global startup, I am looking for the best global Certifications.

What else there is? What would you recommend? Also what approach?

Our company is European and our platform is on AWS. However, potential customers also ask about Company's certifications. Platform (AWS) is for them not enough.

That's not how this works. You don't collect certificates.

being certified does not mean that you are secure
customers only care about the certificates they care about

The "best" certification is the one that serves your company's goals the best. If you pursue Cyber Essentials, but your customers want BSI Grundschutz, then you have wasted a lot of time and money. And neither guarantee that you are secure.

Company certificates help you view your company, its processes, people, and technology through different lenses. Choose the lens that will help you secure your company. Your goal is to be secure, not to be certified.

The "best" case? Look through them all and identify which lens highlights gaps that your company should be filling right now (no, you do not fill all gaps all at once at the start). Then use that lens to improve. Then maybe get certified in that scheme, but only if it serves your company's needs.

Here's the approach (for a non-regulated industry - for regulated industries, you swap items 1 and 2):

Get basic competence in your people, processes, and technology for the obvious/common threats
Get compliance with whatever 3rd party stakeholders want (customers, regulators, investors, etc.)
Develop internal compliance to your own standards to ensure consistency
Develop a risk-based approach to target the non-top-line threats to your business
Develop a flexible, adaptive approach to security to be able to quickly address emerging risks

This is the ELITE approach:

Essential
Legal/Legislative (Lender/Ally)
Internal
Targetted
Emergent


GPG why is my trusted key not certified with a trusted signature? When I run

gpg --verify ~/file.asc ~/file

I receive the following:

gpg: Signature made Tue 10 Dec 2016 05:10:10 AM EST using RSA key ID abcdefgh
gpg: Good signature from "Alias (signing key) <john@alias.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: (a fingerprint)
     Subkey fingerprint: (a fingerprint)

The primary fingerprint matches the output of gpg --fingerprints
In my keyring I have:

pub   4096R/abcdefgh 2014-12-12 [expires: 2020-08-02]
      Key fingerprint = (A public finger print)
uid                  Alias (signing key) <john@alias.org>
sub   4096R/xcdertyu 2014-12-11 [expires: 2017-08-11]

I wanted to verify the authenticity of a file with the public key fingerprint. Note that the trust level is level 4 (full trust)

I believe this because:

:~$ gpg --edit-key abcdefgh
gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

pub  4096R/abcdefgh  created: 2014-12-12  expires: 2020-08-02  usage: C
                     trust: full          validity: unknown

Should there be a reason for concern? Thanks for your patience as I learn more about crypto!

The key needs to be verified. If you trust that someone's public key does in fact belong to that individual and they are in your keyring you can use your private key to sign your correspondent's public key and validate it.

So you are Bob and you trust that Alice's public key does in fact belong to Alice, so you sign it with your private key. So Alice's key is trusted to you. Also any keys that Alice trusts, say someone called Chris will be in your web of trust also. So you can also trust Chris, because Alice does. So Chris’s key will be certified with a trusted signature.

Now if Alice trusts that your key does belong to you then she can validate your public key with by signing it with her private key, therefore your key will now be included in that same web of trust.

  a procedure was given to validate your correspondents' public keys: a correspondent's key is validated by personally checking his key's
  fingerprint and then signing his public key with your private key. By
  personally checking the fingerprint you can be sure that the key
  really does belong to him, and since you have signed they key, you can
  be sure to detect any tampering with it in the future. Unfortunately,
  this procedure is awkward when either you must validate a large number
  of keys or communicate with people whom you do not know personally.

  GnuPG addresses this problem with a mechanism popularly known as the
  web of trust. In the web of trust model, responsibility for validating
  public keys is delegated to people you trust. For example, suppose

  Alice has signed Blake's key, and

  Blake has signed Chloe's key and Dharma's key.

  If Alice trusts Blake to properly validate keys that he signs, then
  Alice can infer that Chloe's and Dharma's keys are valid without
  having to personally check them. She simply uses her validated copy of
  Blake's public key to check that Blake's signatures on Chloe's and
  Dharma's are good. In general, assuming that Alice fully trusts
  everybody to properly validate keys they sign, then any key signed by
  a valid key is also considered valid. The root is Alice's key, which
  is axiomatically assumed to be valid.
  Trust in a key's owner

  In practice trust is subjective. For example, Blake's key is valid to
  Alice since she signed it, but she may not trust Blake to properly
  validate keys that he signs. In that case, she would not take Chloe's
  and Dharma's key as valid based on Blake's signatures alone. The web
  of trust model accounts for this by associating with each public key
  on your keyring an indication of how much you trust the key's owner.

  There are four trust levels.

  unknown

  Nothing is known about the owner's judgement in key signing.
  Keys on your public keyring that you do not own initially have this
  trust level.

  none

  The owner is known to improperly sign other keys.

  marginal

  The owner understands the implications of key signing and
  properly validates keys before signing them.

  full

  The owner has an excellent understanding of key signing, and his
  signature on a key would be as good as your own.

  A key's trust level is something that you alone assign to the key, and
  it is considered private information. It is not packaged with the key
  when it is exported; it is even stored separately from your keyrings
  in a separate database. The GnuPG key editor may be used to adjust
  your trust in a key's owner.

Read more here

Also have a look at this awnser from Server Fault


OS (or platform) agnostic metrics to understand if a system is compromised? For Windows-based systems, I have seen that changes to the Registry or System Directories are some of the things which are used to track if a machine has been compromised. Similar things must exist for other platforms- and I must admit that I am unaware of them.

My curiosity here is that what are the best metrics which a security personnel may want to leverage (at the host itself or at the Network-admin level) to decide whether a system has been compromised, and do them in an OS-agnostic way? That is, these metrics should not change - irrespective of Windows, *nix, Mac, or handheld devices with Android etc.

There is no simple set of metrics I'm afraid. Modern computers are designed to be general purpose and so are very complex.

Modern compromises may also be complex. Many Windows compromises are very hard to detect and certainly wouldn't touch the registry.

Some changes to look for across systems are:

Changes to the boot sector
Changes to system files that don't match controlled updates
Changes to configuration files that don't match controlled updates

From this, you can probably recognise that you need to have very tight change controls and methods to track changes.


Does having multiple nearly identical copies of an encrypted file make it easier to decrypt? I store my passwords in an encrypted database file in the cloud. That is, my KDBX files from KeePass are stored in a cloud storage server, let's say it's Dropbox. Dropbox, whether they admit it or not, probably keeps a very long history of my files. If someone were to attempt to decrypt my KDBX file, would it help them if they had successive copies of my KDBX file over time? I sometimes update just one line in the file and re-sync to Dropbox. Are these files engineered in such a way (i.e. without some sort of random seed) that would give someone great advantage in decrypting the file if they studied successive copies of the file?

If you are using Keepass 2.x then your .kdbx file is encrypted using AES.
Every copy of your file will be different from your previous ones.

Without the knowledge of what was changed, I think it is not possible/easy/feasible to compare and run any sort of decryption against multiple files.


Selinux: How to log/monitor all accesses to a file? Does SELinux support monitoring accesses to an object type? I would like to log all instances where sensitive files are accessed.

Yes, SELinux can be used to log accesses, not just denied accesses. See this message for some details on how to do it. This documentation may also be useful.


Is this an evidence of a Skype communication being spied on? A couple of days ago I was having a conversation using Skype, then I wanted to share a link to a page with the interlocutor. I didn't want to let her understand the link content by just looking at the URL so I shortened it with Google shortening service, then I wrote her the link.

The service let me know how many times (telling also the referrer and the browser) the link has been clicked. I noticed immediately that someone located in U.S clicked the link (identifying as Chrome and www.google.co.in as referrer).

(Firefox clicks are mine)

I asked to the interlocutor if she pressed the link (even though we're in Italy she may have some strange network configuration), but she ensured me that she didn't.

Should I suppose that someone is spying my Skype conversations?

Update 1 - Unshared links details

I just noticed that 9 days ago I created a link with the shortener, but then I did not share it with anyone, only me clicked it and this is the result of the Google charts:

So can I exclude that the link I shared on Skype was visited by Google (if it was, why this link is not visited by no one?), or at least that if Google visits it they don't show their visit in the Details page?

(I have more than one link generated and not shared and no one of them result visited by Google or other except me)

Update 2 - All the shared links are visited by someone who shouldn't!

I also noticed that all the links I shared with Skype in the last 2 weeks have been visited at least once by a Chrome browser (with Google referrer), the most particular is this:

Total visits are 5, one is mine (the only Firefox), another one (with Chrome) is the click done by the Skype interlocutor (I'm pretty sure that she visited it just one time because the count of visits from Italy is 2 (my click and her's)).

Who made the remaining visits? If it was Microsoft, why the referrers are www.google.com.br and www.google.com and the browser identifies as Chrome?

Update 3 - About Skype URI preview

@Ankit Sharma said that it is possible that Skype URI preview functionality is looking at the link I shared, so I wrote a simple C# program to check this, here is the code:

var request = (HttpWebRequest)WebRequest.Create(theURL);
request.UserAgent = "Mozilla/5.0 (Windows NT 6.1; WOW64) SkypeUriPreview Preview/0.5"; // This is the UserAgent he wrote in his answer
var response = (HttpWebResponse)request.GetResponse();
using (var sr = new StreamReader(response.GetResponseStream()))
    sr.ReadToEnd();

I run this code and then I checked the Details but it didn't record anything.
To check if my program was buggy I tried changing the UserAgent to Opera/9.80 (X11; Linux i686; Ubuntu/14.10) Presto/2.12.388 Version/12.16 (taken here) and rerun it, then I checked at the Stats and it is now showing an Opera click.

So I think that it is not due to Skype "functionality" that the suspicious clicks appear.

Given the information you have provided I'd say that it's google shortener visiting the url to check it for security purposes: "Our spam detection algorithms are automated, and routinely disable suspicious goo.gl short URLs" see here.

Back in 2013 it came out that Microsoft monitors skype conversations for HTTPS urls. It then visits these urls purportedly for "preventing spam, fraud or phishing links" (more info here, or on google), so regardless you need to be aware that skype is not suitable for secure text conversations.

UPDATE

So I've just seen your updated information in your question.

I'd still say that at some point known to themselves, something at google will probably hit the URL, either for indexing or security. However thinking about it I wouldn't have expected any of the google's own crawlers/bots to appear in their own statistics; as they're not clicks and they wouldn't want to affect the statistics they present you with, and the bot(s) would visit the destination of the shortened URL, not the shortened URL itself.

If the original shortened URL led to a system under my control I'd now be looking for web server log files to see what requests have been made.

There's always the possibility that there's something else on your machine, or on the machine of the person you sent the URL to, which is responsible for the activity. That could either be something benign or not.

Another thought is that since 2013 Microsoft have changed how their spam preventing system works, but I can't see it having a chrome user agent string!


Where to get/buy a CSR generated S/MIME certificate I'm not sure if the question is eligable for this board as I ask for concrete service providers which can be kind of advertisement, but there is also technical issue involved, so I give it a try.

My concrete scenario is as follows:

I want to use S/MIME for EMail encryption. My decision was made in terms of S/MIME as all default E-Mail clients support S/MIME but not PGP without additional plugins. I also want to obtain a trusted certificate and not a self signed one because it will be easier to use with all contacted people in mind.

Now to the problem:
I want to be future safe with my EMail archives.
As far as I researched, most CAs create their S/MIME certificates with the html < keygen > tag. This lets the browser create a new private public keypair. No problem so far. However, a certificate is usually valid only 1-3 years. If I want to renew my certificate, I have to create a new private/public keypair from the browser. In terms of archiving my emails this leads to a bunch of keys which I have to store/backup and reuse if I want to read an archived email. Furthermore, I will have to try which key is the correct one for decrypting or need the concrete datum and a list at which time which keypair was used.

As far as I understand, this shouldn't be a problem with certificates I receive from CSR requests. I can reuse the CSR every time my certificate expires and keep the same key for all my mails over all years.

So now to the questions: Do you know any CA which offers S/MIME certificates generated by a clients CSR?

Is it even possible to use a default server certificate for S/MIME? (With another email then webmaster, root, ... @mydomain.com but something like theo@mydomain.com which is not a default email adress for getting a class 1 domain validated server certificate)

Or do you have other ideas how to obtain long time durability without a mess of keys?

The theory is that as long as you keep your old keys, your email software will still be able to decrypt your received emails. That the certificate is expired means that other people won't accept to use your old public key to send you new encrypted emails, but reading your mailbox on your side does not entail using your public key or your certificate, only the private key. In other words, certificates expire, but private keys do not. Note that usual email software indexes keys by certificate (they have a certificate, and the certificate links to the corresponding private key) so you'd better keep the certificates around, even if expired.

Under this theory, there is no problem in generating a new key pair whenever you want a new certificate, except maybe storage space for accumulated private keys. One RSA private key would take less than 2 kB, so once key every 3 years will not fill your disk up any time soon. However, this may be an issue if you keep your private key on a smart card: smart cards are not eternal and not easy to backup, so they imply a risk of key loss (and thus data loss). Reusing the same key pair for a new certificate, instead of generating a new one, will not help for that, anyway.

Professional CA are supposed to follow their Certification Practice Statement which often requires new keys for certificate renewals. This requirement can be there for a lot of reasons, not necessarily good ones. One argument, for instance, goes thus: key cracking algorithms take time; by using a long-lived key (key life extending over many years and certificate renewals), you are giving more time to the attacker to break your key. This is not a very good argument because breaking an old key is already interesting for an attacker (it grants access to old emails), but that's a nonetheless widespread argument. Forcing new key pairs is also an easy way to enforce longer keys on a regular basis. Therefore, many CA will not easily accept a pre-made CSR.

Of course, you can potentially alter your browser's code (assuming it is open-source) to pretend to generate a new key, but actually reuse the previous one. The CA cannot really prevent that, unless it checks explicitly that your new key is distinct from the previous one.

Another facet of the issue is that encryption keys should be escrowed (i.e. backupped somewhere). Indeed, losing your private key implies using access to old emails encrypted with that key. So the storage policy for your private key is already complex, out of necessity. Enlarging that policy so as to be able to cover a dozen keys instead of one seems unlikely to be that much an issue.

Summary: while this does not answer your exact question, I would recommend that you do not insist on keeping the same private key across certificate renewal. Generating a new key pair ought to be fine, and it is at least arguable that changing the key is "A good thing". A one new certificate per 3 years, or even per year, it won't be "a mess" before your own demise (which we wish you to be as far in the future as possible).

Key life cycle management is a hard problem. Though simplicity is, all other things being equal, a good thing, there is a point at which too much simplicity begins to degrade usability or security.

("One Ring to rule them all" looked like a good idea at the time.)


Can I have push notification authentication without a third party app? I was reading up on the latest security meta for 2fa and learned that sms is not a secure way to conduct device verification due to phishing concerns. It seemed most articles/blogs stressed the importance of push notification authentication. Essentially, you get a push notification sent to your phone on every log in attempt, which allows you to confirm or deny the attempt. However, this is all contingent on already having third party apps installed, like Authy, which have api's that send and receive the notifications.

However, requiring users to already have a separate app installed would pretty much murder sign up conversion rates, specially in the beginning. Yet it seems that if I were to build out a push system endemic to my app, it would have the same functionality, while cutting out the third party, since all they really are offering is an existing api (which seems easily replicable). Is this correct? Or would I be missing some security features that only existing third party apps have?

(Let's assume that we're only worried about phishing/MITM/social engineering attacks which aim at stealing log in credentials/one time passwords and not actual stolen phones, in which case my proposal would have obvious problems, since the push system is tied to the app on that physical device)

When you are using SMS, you are authenticating the user's sim as the additional factor. Whereas in case of push notification, the user's mobile device is acting as the additional identity provider.

You can definitely use push notification from your app to authenticate the user's mobile device and will not be missing on any functionality from security point of view. Apps like authy provide more convenience to the user as it provides second factor in different forms and not just push notification. For example, push notification might not work when the device do not have an active internet connection. Apps like authy or google authenticator also provide the time stamp based soft tokens that works even without internet.

If more people go with authy you can safely assume that many of your users have it by default and it doesn't act as an additional barrier for most of your user base. It is a trade off  on convenience than security on whether to go with authy or any other third party vs. sending push notifications via your own app.


sniff SSH password on the server Is it possible on the server to log the password encoded by the remote user inside a log.
I want to make a honeypot to see the type of user/password used.

If you run ssh in full debug mode you can have it log the content of all packets and then go back and extract the passwords from that. you can do this bu running

ssh -dddddddd

or add it to your /etc/ssh/sshd_config:

LogLevel DEBUG3

this runs it once, in non-daemon mode and logs way more than you care about. you can improve this by disabling the sshd service and running ssh with the -ddddd from xinitd.

At work I currently maintain an open-ssh fork that includes this ability because it uses an external web service to verify the passwords. If you can afford to maintain an open-ssh fork it will likely give a cleaner experience.


Testing a black-box for sound authentication session config How would I test that a website I'm successfully authenticated on (currently in session) has set my session ID in a safe way and isn't vulnerable?

I believe a session ID should be obscured at the very least (rather than referencing an auto-incremented id, for example), so I'd like to check this. Other than that, I'd like to look at how the session ID is set (I think - is this of relevance?). And also, how can interrogate the session ID? I've fired up dev tools and had a look in the cookie request header, but it doesn't appear to be in there.

This can include many test cases. Go through OWASP link on this.
However, I want to discuss a few cases.
1) Session Fixation: Ensure that the session ID is set to a new value after successful authentication takes place.

2) Session ID length: Must be of at least 16 bytes. (This is from OWASP page)

3) Session ID Entropy: Must be unpredictable (random enough) to prevent guessing attacks. You can use Burpsuite or other tools to check randomness.

4) Secure and HTTP Only Attribute: These need to be set for the session IDs.

5) Check whether session IDs are cleared from both the browser and the server side( and not only browser) after logout.

6) Ensure the response from the server in which "Set-Cookie" header is present and set the new value of the session ID, this page should not be cached. As then, it will be cached at all the intermdediate proxy and gateways.


How can I inject cookie from Wireshark into a browser sesson For education and research purpose, I need to inject a cookie value into my browser to allow me login indirectly (without entering the user name and password).

I collected traffic during a login session using Wireshark. I have the cookie value. I want to inject it to login to the same website used during the login when the Wireshark was collecting the traffic (including the cookie).

How can I inject the cookie into my Firefox browser?
The value looks like (where I replaced letters and numbers with xxx):

   Cookie: FN_cookie_accept-20180525=true; PHPSESSID=xx; glt_3_xxx=yy

EDIT:

Please note that I could not find an answer in this post. If you see it answers my question, please provide steps (how to do this in steps?)?

Browse to the website you want to place cookies on.
Press F12 to open the developer tools.
Press F1 to open the settings.
Check the "Storage" checkbox to enable this tab.
Click the "Storage" tab. The cookies for this page are shown.
Click the + icon to add a new cookie.
Double click the Name field of the newly added cookie to change the cookie name.
Double click the Value field to change the value.
Refresh the page to perform a request including the new cookie.


What is an n-day security attack? There are several attacks types in computer security. For instance, zero-day attacks consist of attacks that use undisclosed exploits. In contrast, what is an n-day attack? Is it a security concern?

A zero-day attack is an attack that relies on an undisclosed vulnerability in the design or implementation of a system in order to violate its security.

Most commonly, such attacks consist of using zero-day exploits to access information systems or execute code on privileged systems. Such exploits are called 'zero-day' because security administrators have had no time to mitigate them between the moment they were disclosed and the moment they are used to perform attacks.

In contrast, the typical responsible disclosure procedure involves privately contacting software vendors and exposing the vulnerability to them, and leaving them reasonable amounts of time to fix the vulnerability and distribute the fix to their clients and users. This process can require coordination between multiple software vendors and distributors so that they all release and distribute fixes or patches on the same day. Indeed, releasing a fix helps attackers understand the existence of a vulnerability in the first place, and teaches them how to attack the systems that have not been patched yet.

This is where 1-day or n-day exploits kick in: now that vendors have admitted to a fault and started repairing it publicly, attackers can write exploits that target those systems that were not yet updated since the time of disclosure. The term 1-day or n-day indicates that a delay of 1 or more day / n days has occurred between the time of disclosure and the time a system is attacked. The goal of vendors, distributors and administrators is then to patch systems as quickly as possible to avoid n-day attacks.


“Encrypt and wipe” procedure on Android Lollipop? I know a lot of people are advocating an "encrypt and wipe" procedure for selling used Android phones. But according to the AOSP website, in Android 5.x Lollipop:

  Created fast encryption, which only encrypts used blocks on the data
  partition to avoid first boot taking a long time.

More specifically, when Lollipop encrypts a previously unencrypted device:

  To enable inplace encryption, vold starts a loop to read each sector
  of the real block device and then write it to the crypto block device.
  vold checks to see if a sector is in use before reading and writing
  it, which makes encryption much faster on a new device that has little
  to no data.

In other words, Google made a disturbing choice to only encrypt whatever space is marked as "used" in storage, not any of the free space, which could very well include unencrypted information deleted prior to encryption. Unless I'm mistaken, this is a massive security risk, makes the "encrypt and wipe" procedure nothing more than a useless placebo, and makes physical destruction the only way to reasonably secure an unencrypted Android Lollipop device.

Is this assessment of the Lollipop's encryption system accurate?

Does there exist a method to force Lollipop to use full-disk encryption instead of the "fast encryption" nonsense?

You're making the common mistake of asking the wrong question: “is this system secure?” instead of “is this system secure in this scenario?”.

Google's choice to not encrypt unused space makes perfect sense in the typical usage scenario where a user decides to encrypt their data, and all their current and future data is encrypted. The choice not to encrypt unused space has only minimal security impact in this scenario: on a young device, it reveals how much space has been used. Eventually, as blocks are allocated and freed, all blocks will end up encrypted, making it impossible to tell which ones are currently in use and which ones are merely formerly in use.

Data that was stored on the device but is no longer accessible is not encrypted by this procedure. This is a reasonable design, since this is an encryption feature, not a wipe feature.

You can still leverage the encryption feature to make a wipe feature by first turning on encryption, then filling the partition with data — any data. For example, if you have root shell access, cat /dev/zero >/data/zero && cat /dev/zero >/cache/zero && rm /data/zero /cache/zero after turning on encryption will wipe the free space on the partitions containing /data and /cache. Refer to your favorite Android experts for how to accomplish this without root access.

Note that even pre-Lollipop, calling the procedure you describe “encrypt and wipe” is a misnomer. If there was a true wipe, encryption wouldn't be useful, the data would be gone anyway. It's really “encrypt and reset”, where the reset makes data inaccessible through normal means, but not wiped.


Can mobile network operators read WhatsApp metadata? After turning on end-to-end encryption for WhatsApp is it possible for the network operators to read the metadata of the messages being exchanged?

I see here (in Transport security) that metadata is also protected. Can someone shed more light on this?

There is no reason to think a network operator can access the data.

The document says it clearly:

  Encrypts metadata to hide it from unauthorized network observers.

In other words, you are questioning that what's said in the document is false.

The only people that could shed more light on this would be WhatsApp or Open Whisper Systems (the company that created the encryption system), and as you can figure out, they are not going to give you details..


google certificates correct CA I view certificates of https://www.google.com.ua/

So I thought, when requesting via cURL, if I point by CURLOPT_CAINFO to those certificates (GeoTrust Global CA and Google Internet Authority G2 in a bundle or whatever), the validation of google's certificate would be passed. But the only CA that does it is the Equifax Secure CA (discovered it by plain enumeration of git's CA bundle). Could someone explain why is it so? Thanks a lot.

UPD: it's not only google's behaviour, another site behaves that way too, so I suppose either I misinterpret something (which is likely) or some wrong information is being shown (again, why is this happening)

This is most likely an obsolete "bridge" now leading to the wrong place.

There are two valid trust chains for this cert. There is a root cert for GeoTrust Global CA, valid from 2002, which is in current Windows/IE and Firefox stores (and Java); and also a "cross-signed" cert for that CA under Equifax Global CA as follows:

Data:
    Version: 3 (0x2)
    Serial Number: 1227750 (0x12bbe6)
Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
    Validity
        Not Before: May 21 04:00:00 2002 GMT
        Not After : Aug 21 04:00:00 2018 GMT
    Subject: C=US, O=GeoTrust Inc., CN=GeoTrust Global CA
    Subject Public Key Info: <snipped: same as root>
   X509v3 extensions:
        X509v3 Authority Key Identifier:
            keyid:48:E6:68:F9:2B:D2:B2:95:D7:47:D8:23:20:10:4F:33:98:90:9F:D4
        X509v3 Subject Key Identifier:
            C0:7A:98:68:8D:89:FB:AB:05:64:0C:11:7D:AA:7D:65:B8:CA:CC:4E
        X509v3 Basic Constraints: critical
            CA:TRUE
        X509v3 Key Usage: critical
            Certificate Sign, CRL Sign
        X509v3 CRL Distribution Points:
            Full Name:
              URI:http://crl.geotrust.com/crls/secureca.crl
        X509v3 Certificate Policies:
            Policy: X509v3 Any Policy
              CPS: https://www.geotrust.com/resources/repository
<snip signature>

This is apparently a "bridge" cert, often used when a renamed (here) or new CA root is created and wants to temporarily leverage the existing trust of an older CA root; the Equifax root is valid from 1998 so in say 1999 and 2000 there were lots of clients that would know the Equifax root and not the GeoTrust root. 12 years later it should be obsolete.

Running 'openssl s_client' confirms www.google.com.ua is providing in the SSL handshake its own cert, the Google Internet Authority G2 intermediate cert, and the bridge cert. IE, FF, and Java are all smart enough to ignore the bridge and use the GeoTrust root which they have internally stored. OpenSSL, which curl uses, is not, or at least not yet; thus you must tell curl to give OpenSSL the Equifax root. (The OpenSSL 1.0.2 release, currently in beta, is announced to have enhancements in the area of cert chain validation, which I haven't looked at in detail yet.)

EDIT 3/13: I can't comment on my answer(!) so adding here. As I said,
there are TWO certs for GeoTrust Global CA: one root, and one "bridge".

IE/Windows and FF DO have the GeoTrust root; you already saw it in Certification Path in IE or FF with the webpage open, or you can look directly in the truststores with InternetOptions/Content/Certificates/TrustedRoots and Tools/Options/Advanced/Certificates/Authorities. Both also have the Equifax root, but don't use it here. Both IE and FF display the certification path used even though it differs from what the server sent; that may be "wrong" in one way of looking but "right" in another.

A root cert is always self-signed; that's necessary to be a root (not always for an anchor, but leave that aside). The GeoTrust root cert is a root. The GeoTrust bridge cert is not a root, it links to the Equifax root cert which is a root. And, again, the Equifax root is the one curl + openssl needs.

EDIT 9/01: https://knowledge.geotrust.com/support/knowledge-base/index?page=content&id=AR1426&actp=search&viewlocale=en_US&searchid=1283360269668 confirms this is a bridge cert back to Equifax.

UPDATE 2017/03/28: first, OpenSSL 1.0.2 did add -trusted_first which uses the GeoTrust root if present and ignores the bridge cert. Second, this is now more important because the Equifax root has been removed from the Mozilla/NSS truststore, and thus the curl-project CAfile used by many clients, see https://serverfault.com/a/841071/216633 .


Linux kernel 3+ system call table modification detection Is there any available tool which can check kernel 3+ system call table for modifications?

Also I want to know, is there any automated general tool to check Linux for unknown rootkits? Not like rkhunter etc. which is mainly signature based, I want something like GMER for Linux, check for code modifications, kernel hooks, function hooks, etc.

It is impossible to detect kernel modifications from inside the system. Whatever rootkit detector you use, the rootkit can be programmed to lie to it. If someone controls your kernel, then they control your system, not you, end of story. GMER suffers from that flaw too, it is intrinsic in the operating principle: it only finds rootkits that aren't good at hiding.

It is possible to detect kernel modifications from the outside. A common technology for that purpose is a TPM, which is a piece of hardware. It's a bit more complicated than “check the system call table for modifications” because the system call table is just a small part of the kernel, a modification anywhere else can have similar-reaching consequences. TPM works by taking a snapshot of the system from time to time, and comparing these snapshots with a reference snapshot. The TPM stores only hashes, not the whole memory image, so the snapshots have to match bit-for-bit. Loading modules changes the kernel, so you need to have a fixed set of modules as well as a fixed kernel version.

Detecting a kernel modification is useful only if there is some place to report it to. The TPM can't tell the user, because it has no user interface. The way to leverage a TPM is when you use your computer to authenticate to a remote service. The TPM sends a measurement of your PC, and the remote service compares that with a reference value and decides whether your PC is in a known good state or not. An unknown state could be a version upgrade or a compromise, the remote service has no way to know, so usefully using a TPM requires more infrastructure to manage upgrades.

Instead of a hardware TPM, you can implement similar functionality in a hypervisor. This requires no special hardware, but of course implies that your system runs in a virtual machine.


Why does Android care about differentiating multiple fingerprints? I was reading through the Android Compatibility Definition document after a friend pointed me there while we were discussing fingerprint scanners and other biometric authentications.  I noticed this requirement that seems unusual:

  MUST NOT enable 3rd-party applications to distinguish between individual fingerprints.

I found this article which seems to be wondering the same thing, with no conclusions, although one person in the comments suggests that it might be a way to avoid patent infringement.  Now, I can definitely see patent issues as being possible - one useful patentable idea that comes to mind is a phone having two modes, the 'real' mode that you use, and a 'fake' mode that hides personal information, contacts, etc, which you unlock with a different finger, unknown to a person trying to force you to give them access.

I haven't been able to find any definitive answers, though, so I'm curious if there's something I'm overlooking.  Are there any known security vulnerabilities relating to a program being able to distinguish which finger is used to authenticate?

A bit of a wild guess here: privacy and anonymity.

Having worked on ePassport software, I can tell you that developers need to be extra careful when handling users' fingerprint and iris data. Think of how careful we are about storing usernames, passwords, credit card numbers, etc, then consider that in the case of a breach, passwords and credit card numbers can be changed ... fingerprints not so much. I support the idea of being careful around biometric data - even if there's no obvious reason for it.

That said, here's an example where it might matter:

If you've set up your device to have a shared account used by multiple people, allowing apps to distinguish fingerprints would de-anonymize the users.

On personal devices like phones and tablets that's probably an obscure use-case, but with Android being used in more and more embedded devices, keeping 3rd party apps behind a privacy barrier makes sense. Take for example a livingroom entertainment system that's used by the whole family: the music streaming app needs to know whether it's authorized to bill you for purchases, but does not need to know which human did the unlocking. If you choose to give the app access to this information, then cool, but there's no reason for it to know it by default.

The Principle Of Least Privilege would say that if an app needs access to your biometrics, it should have to request that permission explicitly - just like any other permission in Android. By forbidding fingerprint device manufacturers from leaking distinguishability information to apps, Android has the ability to control access to this information through the OS' permission system.


Is it possible to determine password strength without knowing the password? I have just got some report of a penetration test and one of the recommendations was to strengthen passwords. I however realized that no passwords were provided for the testers, and I wanted to find out if it was possible to determine the strength of a password without actually knowing that password?

I would figure there are two ways they've come up with the information that they drew that conclusion from.

They ran the net accounts /domain command on a users computer which dumped the password complexity requirements for your organization (assumes Windows / Active Directory)
They successfully brute forced (or guessed) user passwords because they were weak. Recent password dumps like LinkedIn have provided a trove of real-world passwords that pen-testers have been using in the field to try to crack passwords.

Without further information it's hard to say how they've come to that conclusion (we have no idea what the red team did or what was in scope) but those two ways are how I would assume they did it.


Mixing cheap SSL and EV SSL We are a non profit and have been hosting an online site that accepts payments. It has been getting enough exposure now that we want to put an EV SSL certificate on the site. The question I have is does it make sense to put a cheap $10 cert on www.domain.com and redirect it to https://domain.com with the super fancy EV cert? unfortunately our marketing team has mixed www and non www in many forms so we need both to at least present an SSL. We wanted to purchase one from Digicert but they do not cover the alternative name.

I figured this would work but is there something I am missing and is this a common practice? Thanks!

If you're always 30x redirecting from www.example.com to example.com, then yes, there's no reason this wouldn't work from a UX perspective.  There's certainly nothing stopping it from working from a technical perspective.

It is also certainly common to mix DV (cheap) SSL certs for secondary domains (like CDN domains for example) with an EV cert for the domain the page loads from.  The  browser's green bar is determined by the cert used for the session for the page, and that cert alone.  Beyond that, browsers only care whether or not all resources on the page are in fact loaded over HTTPS; they don't currently care whether or not the domains serving those resources present DV or EV certs, and there's no effect on the UX.


Can I use crypto.getRandomValues to create a private key? In the window.crypto spec:

http://www.w3.org/TR/WebCryptoAPI/#RandomSource-interface

It says explicitly:

"Do not generate keys using the getRandomValues method. Use the generateKey method instead."

but generateKey does not support secp256k1/ECDSA (bitcoin related).

Why does it say that? Because the random numbers are not crypto secure? or because the key needs to be verified afterwards? (if it is the later case, we can verify it).

Well, for one, ECDSA is not an encryption scheme, but a digital signature algorithm.

The generic purpose of a crypto API like window.crypto is to give you access to implementations of some cryptographic algorithms. These implementations may be based on software or hardware. In particular, an implementation may be a piece of tamper resistant hardware (a HSM or a smart card) that can generate keys for some algorithm, and store them, without ever letting the key exist outside of the hardware. generateKey() handles such cases. With getRandomValues(), you can only generate a bunch of bytes in the RAM of the computer.

Moreover, private keys often need some mathematical structure. In the case of a ECDSA, a private key is a big integer in a definite range (1 to n-1, where n is the order of the curve subgroup generator); if you want to produce such a key yourself, with getRandomValues(), then you must use some big-integer arithmetics to make sure that your value will fit in the proper range. There again, generateKey() will produce a key with the right structure for the algorithm at hand.


Autopsy/SleuthKit in the courthouse? I am studying digital forensics and have been working with both AccessData's FTK and Autopsy to analyze disks for different assignments.  I keep hearing that Autopsy findings should not be admitted in a court of law due to a lack of proof of reliablity, integrity, etc.

This is bothersome, as I find Autopsy to be the better option of the two digital forensics tools that I have used.  I know their are other options out there like EnCase, but I really find Autopsy to be a nice system to work with.  Has anyone here presented digital forensics findings that were derived from Autopsy or Sleuth Kit in a court of law, or found literature/precedence regarding this question.

I see that Autopsy received early funding from the U.S. Army and currently receives funding from the DHS, so I have to think it is at least somewhat regarded as a professional grade tool.

The reliability & expertise in court is the responsibility of the examiner, not the tool. Voir dire will audit your training, experience, past testimony, etc. You can't audit or voir dire a tool, only a person (examiner). Use whatever tool you like, validate it with other tools as needed, update your tools regularly and don't be afraid to make a change if one tool isn't working for you. I used EnCase for years. I switched to Xways for a number of reasons. I also will use Autopsy to validate & for supplemental reasons. I may almost use Autopsy exclusively, but it doesn't create the forensic image, so that's a challenge.
Anyway, that's my 2 cents. Good luck!


Can I block based on MAC address? If I block an IP, the attacker can work around the block by taking a new IP or use a proxy. Is it possible to make a ban based on MAC address? I want to block at the webserver level so that unwanted users don't create unnecessary traffic to the site.

Is the MAC address sent as a part of HTTP request?

In short, the answer is no, you usually can't block based on MAC address. And if you could, it would be useless. To understand why, you must know a thing or two about how the internet works.

Communication between devices is commonly done via the Ethernet protocol (wiki), and despite the source and destination being identified by IP, actual communication is done per MAC. Imagine the following network:

If the client wants to send a packet to the server, it first checks whether the server is in the same subnet. Nope, the server has a 10.x IP, and the client an 192.168.x IP. The client then sends it to his router, R1, in the hope that it will be able to forward it to the destination. The packet contains:

Source IP:       192.168.1.100     (belongs to: Client)
Destination IP:  10.1.1.1          (belongs to: Server)
Source MAC:      01:01:01:02:02:02 (belongs to: Client)
Destination MAC: 02:01:01:02:02:02 (belongs to: R1)

Then R1 is like "Oh, that IP is somewhere on the internet". It changes the source IP to the public IP (so that the server can send a packet back), and forwards it to R2. The packet now contains:

Source IP:       172.16.1.1        (public IP from R1)
Destination IP:  10.1.1.1          (belongs to: Server)
Source MAC:      02:01:01:02:02:02 (belongs to: R1)
Destination MAC: 03:01:01:02:02:02 (belongs to: R2)

As you can see, the destination IP doesn't change, but the MAC addresses changes every time it gets forwarded (by a router) based on which router it is forwarded to and which router it came from.

Moving forward, R2 will not tamper with any of the IPs like R1 did because it is not a NAT router (like most consumers have). R2 will merely forward the packet.

In the end, the server will only be able to see the MAC address from R3. For the communication to work, that's all it needs to know besides the original IP from R1. (When a reply packet comes back at R1, other things make sure the packet finds its way to the client.) If you want to know why not all communication is simply MAC-based, have a look at this question on serverfault.

One exception to this is when the client is inside the same LAN as the server. As I mentioned, the client first compares the IP subnet of itself and the destination. If it's the same (e.g. 192.168.1.101 and 192.168.1.44, when on a /24 subnet), the communication is based on MAC address. The client will broadcast a message on the LAN, asking for the MAC belonging to the server's IP, and then send it to that MAC. The packet will still contain the destination IP, but there is no router between the two. (There may be, but then it will be acting as a switch or hub, not as router.) But this is probably not the scenario you had in mind.

If you could determine the MAC, that would be a pretty big privacy violation. Since your MAC address arguably identifies you uniquely on the globe, advertising networks would have no problem tracking you, also without tracking cookie or any other methods.

Blocking an attacker by MAC would be the same as blocking him/her by cookie because it is controlled by the client. Currently it's almost never changed because there is almost never a reason to, but if you could determine and block an attacker by MAC, he could simply change it. An IP addresses must be globally recognized in order to be routable, but a MAC doesn't have this issue.

Also, an attacker could block clients whose MAC he knows by spoofing that MAC address and then triggering the block. Whoever really uses that MAC address would be prohibited from using the service.

Conclusion: If it were possible it would be rather ineffective and while introducing a DoS vulnerability, but since you can't make the client send the MAC along with HTTP headers or something, it's just not possible outside the same LAN.


Different types of segmentation faults in Linux In Linux, when the NX-bit triggers the segmentation fault seems to be "error 15", whereas a more typical error, such as attempting to read from invalid memory, results in "error 7", (seen from dmesg output).

What other error codes exist? Where are these error codes defined, and what is their true meaning?

I'd like to see a full list so that when I do get a segmentation fault, I'm able to get some hints about what the reason is. I'm not sure how useful this really is, but I'd still like to know.

According to a similar question on StackOverflow, the error codes are architecture specific. The codes should be documented in arch/*/mm/fault.c as part of the kernel source code.


Cross domain iframe security How exploitable is a site listening to browser messages from anyone?

I am working on a site where I have found some iframe issues. The case is that site A has an iframe of site B, and site A listens to 'messages' from anywhere and then it can perform two different actions when a message comes in:

Set document.location = "incoming message data"
Create a form, and set the action attribute value to "incoming message data", add it to the DOM and then submit the form.

This means i can set up site Evil, include an iframe of site A, and then start sending arbitrary messages, for example "javascript:alert(1)" which will in both of the above cases execute the javascript in the iframe context. Before I report this to the people I work for, I need to have a scenario in which this would be a major issue. And this is where it gets tricky, because I cannot really come up with a scenario where this would be a significant issue. The ideas I have are:

I can execute javascript in the context of site A, but I cannot get cookies due to SoP.
I could set up a key listener on site Evil and make site A iframe fill the screen asking for a login, in that way harvesting logins for site A. This would require some social engineering to work properly.

But this is the best I can come up with, so my question is, have I completely overlooked something? Googling around doesn't yield any other options.

EDIT:

Obviously this opens site A (whom I work for) up for XSS through site B (who is a semi known company, but still). Another point I am thinking about making is why on earth would anyone do ANYTHING this way? Create a form and submit and answer with some received data? I can't figure out a good reason to do it like this, maybe any of you good people can?

EDIT2:

It seems there is no way to bypass Same Origin Policy even though I can execute arbitrary javascript in the context of Site A through the iframe located on Site Evil. So there is nothing about this 'vulnerability' that makes it any different from an attacker to get a user to click on an arbitrary link.

You could definitely hijack the session by getting cookies, if you can execute the Javascript in that page/frame by sending the message.

Refer : How to send cross domain post request via javascript

The minimal requirement here is, you'll need a server which you control. So that you can configure the Access-Control-Allow-Origin header of the response generated for your AJAX Request.


Benefit to specifying JSON Content-Type character set? According to the OWASP Application Security Verification Standard:

  V11.3 Verify that every HTTP response contains a content type header
  specifying a safe character set (e.g., UTF-8).

According to the RFC for the application/json Media Type:

  JSON text SHALL be encoded in Unicode. The default encoding is UTF-8.

  Since the first two characters of a JSON text will always be ASCII
  characters [RFC0020], it is possible to determine whether an octet
  stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking
  at the pattern of nulls in the first four octets.

If your encoding is in fact UTF-8, this implies there is no security benefit to setting the Content-Type header to application/json; charset=utf-8 instead of just application/json.

Is it reasonable to make an exception to the OWASP rule for application/json?

Your biggest risk would be older versions of Internet Explorer that attempt to auto-detect the encoding as UTF-7 - called Codepage Sniffing.

It appears that Internet Explorer will only do this for webpages, and not for AJAX requests. Therefore JSON requests should be safe. Moreover, JSON requests do not cause rendering of content directly to the page - they would need JavaScript processing in order to manipulate the DOM, so this would only be of concern when you were retrieving data that has supposedly been pre-HTML encoded. Therefore if the JSON data is HTML encoded on the client, the encoding of the page should take precedence and would not cause conversion of +ADw- character sequences to angle brackets, which is where the risk lies with UTF-7.

So I would say specifying charset=utf-8 is only necessary for Content-Type: text/html pages.


Using digital signatures to identify users Consider the following requirement:

  Bob should be able to verify that a payment request came from Alice.

The above is in simple terms the basic idea, however, in reality Alice would be user A of company XYZ and Bob would be a registered vendor for company XYZ.

My thinking on this was for each company that registers would have their own digital certificate (whether this be purchased by them or purchased by me on behalf of them if possible). When vendors are registered for that company they would be given access to the public key. When users authorise payments on behalf of that company a digital signature would be generated (perhaps using their user ID/email address) and sent along with the request. The vendor would then use the public key to verify that the request came from someone at company XYZ in order to process the payment.

I know the signature would no doubt need to be a bit more complex than just a user ID/email to avoid things like replay attacks/spoofing etc however, at a basic level does this seem the right approach?

I am fairly new to digital certs/signatures to any advice in general would be great.

Your thoughts go into the right direction in my opinion, although I hope I can convince you in the following to take a slightly different route.

Let's analyze your requirements:

You want to guarantee mutually authenticated requests for payment processing, i.e. a client initiating such a process would want to be sure of talking to the right server, and a server accepting a request would like to be sure of the identity of the peer. So the solution has to have server authentication plus client authentication
Integrity of the requests is another must - nobody should have the chance to alter anything in the request while it is on its way

These were the major requirements you listed. I would also add privacy to the mix - you possibly don't want anyone listening in on the traffic to be able to learn what the client purchased or the amounts of money they pay.

And now comes the tricky part. You can indeed achieve these goals with a mix of asymmetric and symmetric cryptography. But I think a manual scheme is not appropriate here, and here's the reasons why:

You are trying to secure the transport and the protection is ephemeral - once the transaction is done, you need no longer persist the request data (unless you try establishing an audit trail)
By securing the transport, you are actually designing a security protocol here. And getting them right is probably one of the hardest problems in cryptography. If you read about the Needham-Schroeder protocol: they were dead serious about this protocol for a couple of years, convinced that it was perfectly fine. And they had every right to do so, being decorated cryptographers and all. But three years later they were presented with a valid attack... you probably know where I'm heading and you yourself already mentioned the various things you would have to care about when trying to make this thing secure...

But not all is lost, because there's a perfectly fine protocol already doing all of the above and much more for you. It's TLS! It supports all of your requirements and has been tested by millions, so chances are overwhelming that your manual solution won't be able to compete with it anyway. And on the bright side, it's also already supported in all popular programming languages, no need for you to invent anything.

PS: When to use signatures vs. when to use TLS: it has always helped me to analyze my situation asking me this question: "Do you want to secure the transport?" vs. "Do you want to secure the data/document?"


Is there any method to prevent/trace DDoS attack? I have a Debian Linux server which runs a few online game services. I have some competitors in this area and I think one of them is behind the DDoS attacks.

I have full access to the router, so I set a few connection rules in Winbox which can detect and drop the DDoSer IP addresses but I think it's not the best way to prevent an attack.

These are some source ip addresses (all from port 53)

38.111.134.26
41.78.27.213
66.232.92.39
66.232.92.43
66.243.192.11
67.43.55.110
67.43.55.111
67.50.161.103
67.59.80.28
67.118.192.2
69.27.136.10
69.27.136.12
69.27.211.200
69.31.186.27
74.114.48.151
116.199.220.101
203.87.92.4
203.161.128.249
203.161.159.10
206.51.97.91
206.158.2.91
209.240.96.6

Is there any method to prevent or trace a DDoS attack?

No - There is no useful way to trace the source of such an attack. A DDoS will come from hundreds or thousands of machines, probably in multiple countries, and probably all unwittingly victims of an attacker.

But yes - you can prevent such an attack. You have 3 possible solutions:

Change IP addresses, so you aren't the target any more.
Buy more bandwidth so your pipe is bigger than the total bandwidth aimed at you.
Buy the services of a DDoS mitigation provider.


A different CSRF token and session ID passed in the request A CSRF token is what a server includes in its response, that is the same token which is passed in the request from the user.

In my case, a different CSRF token is getting included in the request- which is hence generating a 403 Forbidden error.

Along the different CSRF token cookie, a new session ID cookie is also getting included, which should not be the case. I am guessing a new session is somehow getting created and hence including a different CSRF token but I am really not sure how and why is this happening. Seems a sort of re-login is happening.

What is more interesting is that this is happening only for a specific user. Any ideas what might be the case?

The most likely scenario with the information you've given us is that the user has opened a session in one window.  They they open a new browser window, where there initial session times out and they are given a new session identifier.  Now, they go back to their original browser window, and try and submit that form.  This is where your expired information is coming from.


Can a service be Oauth2 provider and Oauth2 client at the same time? Let's say a new application X is an Oauth2 client and allows it's user to signup/login with other Oauth2 providers like Google. So a user U signs up using Google and regularly logins using Google to the application X.

But what happens if X is also an Oauth2 provider? That would be a bad experience for U in applications that allows login with X since the user would be redirected multiple times until the final provider (Google) is reached. And theoretically, the applications that allowed login with X could also become a provider in future. So the number of redirections are not strictly limited to 2.

So is it the case that an application can not be Oauth2 provider and Oauth2 client at the same time?

Yes, this is very common and one of the scenarios facilitated by identity protocols like OAuth2 and SAML.

Let's say you have an application and you decide to outsource identity management, e.g. to Azure AD B2C.

Your application will be an OAuth2 or OpenID Connect client to Azure AD B2C.

Now you want your users to be able to use an email/password combination or login using identity providers (IDPs) like Facebook or Google (the kind of experience login.realmadrid.com has, which uses AAD B2C).

So the user comes to your application and clicks "sign in". Your application will send the request to AAD B2C, which will ask the user to enter email/password and show buttons for Facebook and Google. If the user now clicks one of those buttons, then AAD B2C becomes a client and sends the user to either of those IDPs using OAuth2.

User enters credentials in Facebook or Google, they issue token to AAD B2C, which it will consume and then issue a token to your app.

Now your app doesn't really need to change as additional IDPs are added or existing ones removed, or if IDPs use different protocols because your app only needs to interact with AAD B2C.


Making a content injection target I don't know much about content injection so I'm hoping to draw on the experience of the community here. I'm writing a tool that evaluates public web proxies. I want to know if the proxies are being used for content injection and other attacks. I.e. to determine if they are injecting malware, phishing attacks, or spam into the page being requested via the proxy.  I need to determine which ones I can trust to use myself.  I'm the only client.

To do this, I want to make a webpage that is the biggest target possible (AKA honeypot) in order to encourage the proxies to do their content injection if they do it at all.  I'd like to know if there are there certain keywords, content, or ways to structure a web page that will encourage content injection.  For example, I could have phrases like 'hot girls' in order to encourage porn and viagra advertisements.  Or have frames and iframes in the body of the page in order to give the attackers a place to put the content.

At my end I will compare what was returned by the proxy with what I expect in order to determine if the proxy is changing the content at all.

I already check to see if certificates are changed.  I mostly care about the fidelity of the page content.

What else should I do?

Interesting project.

I expect most proxies that do modify will blindly modify every page, so they can easily be detected.

Some proxies may target specific sites e.g. http://important-bank.com/ You will only be able to detect this by requesting the actual bank's site through the proxy, and comparing it to a version you request directly.

I've also heard ideas of poisoning JavaScript libraries on public CDNs (e.g. Google Hosted Libraries), with a twist being setting a long cache validity time. These would be worth a look.


How do I decide my specialization in cyber security? I have done web security and interested in learning mobile security, IOT security, malware analysis etc. Will doing all of this make me "Jack of all but master of none". I have a limited time to devote how do I decide

Only you can decide your fate. Follow what makes you happy, where your passion is, and as you evolve through your career that drive will change multiple times making you a better candidate to employers. Network with others, goto conferences, and keep on learning!


Install Metasploitable on PC I am a teacher giving pentesting classes and I have a group of students that I have been teaching for 4 years now.

I would like to make a little "hacking contest" in which there is a vulnerable machine, and the children try to get root access to it. In order to do that I have started looking for a highly vulnerable OS that I can install on an external machine (one that I had lying around for a while now). I have found some OSs that are vulnerable such as metasploitable. But they are all designed to be installed on a VM. But that is not what I need. I need an OS that I can burn on a cd, or a USB and installed on a PC.

Why am I not hosting a VM on my own machine? I can do that but the machine that I have is old, and not used. So it will be thrown away. And I really want to make some use out of it.

You should consider using public facing sites for something like this such as Troy Hunt's "Hack Yourself First" [Link]. If your vulnerable server is public facing to the internet, that box is going to be compromised in less than 24 hours and you could put whoever logs into that box at risk.


Keeping AWS account ID secret Must my AWS account ID be kept secret? Can anything at all be done using just the AWS account ID?

From the AWS documentation:

  The AWS account ID is a 12-digit number, such as 123456789012, that you use to construct Amazon Resource Names (ARNs). When you refer to resources, such as an IAM user or an Amazon Glacier vault, the account ID distinguishes your resources from resources in other AWS accounts.

An AWS Account ID can be shared, when required.

Like the documentation says, the main thing anyone can use your AWS Account Number for is to construct ARN's. For example, if I had an AWS Account which held an AWS Lambda function, and someone on another account, who I had explicitly granted permission to, wanted to manipulate it, they would use by account number in the ARN.

arn:aws:lambda:us-east-1:123456789012:function:ProcessKinesisRecords

Again, this is totally limited by the permissions applied on your account. Even if I had a full ARN, unless you give my AWS account access, I won't be able to do anything with it.

API Keys are the things that grant remote control of things, and are dangerous.


How is LastPass sharing secure? I'm trying to understand how LastPass can be secure if it allows sharing passwords with users who have not even created accounts yet.

Their FAQ says, "When you want to share data with someone else, you pull their public key and use that to encrypt the data." However, the forum thread "Password sharing: how is this done securely?" makes it clear that you can share a password with someone who doesn't have a LastPass account because "they will be given an opportunity to create an account."

How can this be secure? The insecure scenario I envision is:

I indicate what password I want to share and what (future) user should receive it
My LP client encrypts the data with a server-owned key and uploads it to the server
The other user creates an account and an RSA key pair
The server encrypts my password using the newly-created public key
The other user's LP client downloads the encrypted data from the server
The other user's LP client decrypts the data using the user's private key

In this scenario, the password is readable by people other than my intended recipient: the admins of the LP server can read it. If the server doesn't store it securely and if they suffer a security breach, even more people can read it. This seems like an edge case, but if the admins are willing to make my passwords available to themselves in this case, I imagine that they are willing to do so in other cases.

The admin on the forum thread linked above and those employees responding to my customer service inquiries either haven't understood the problem or are trying to brush off people who ask about this. (The forum thread is hard to believe because the admin does such a good job of avoiding the security concern.)

According to the linked forum thread, the target sharee is required to create an account before the password is "shared"...

The thread participants claim that no unencrypted shared password is stored on LP servers.  Once the target sharee creates an account and supplies a public key, the target password would be encrypted with the target user's public key on your client side and uploaded to the LP database.

Thread Ref:

by jonat » Wed May 25, 2011 4:46 pm

If you read the user manual about sharing, it sends the recipient an
email inviting them to open a LP account if they don't have one. As
Israel says, nothing is actually shared until the account exists and
the sharing accepted, by which time the keys are in place.