Should JWT's be validated on every request? I have been unable to find a definitive answer to the above question.

We currently use JWTs from AWS Cognito for our Authentication. Currently the JWTs that are returned are too large to use in Cookies (over the 4KB limit) so we do not store the entire JWT in cookie.

Our current process is to login the user, then validate the ID token (JWT) that is received. Then create a FormsAuthenticationTicket and Cookie from this information. The Cookie includes the relevant ID information of the user and the ExpirationDate of the original received ID Token.

This means for all future page loads, we simply check if the Cookie is expired or not. If it is, we know they need to login again.

Would the above work correctly, or does the JWT need to be sent as the cookie and validated on every page request?

To directly answer your question: it's necessary to verify the authenticity of a session token every time you receive a new connection. That doesn't necessarily mean every time you receive a request; if your system is never going to combine multiple users' requests into a single connection (which is very rare on client-to-server but relatively common on, say, load-balancer-to-server) then you can verify a connection's token only once and allow multiple requests over it during the lifetime of the session (though this is still riskier than verifying every request, because somebody might manage to cause the client to send a fraudulent request without knowing the token). Even when the risks are acceptable, if the session ends (user logs out, times out, etc.) before the connection breaks, you obviously need to stop trusting the connection.

As I implied in my comment, for a system like yours it really, REALLY depends on what you're storing in the cookie. For example, if you're storing the expiration data in the cookie value without cryptographic integrity, or worse-yet just relying on the expiration feature of browser cookies in general, that's risky because there isn't anything preventing somebody from modifying that expiry. Cookie expiry means almost nothing security-wise, just that the browser will delete the cookie at that point. Anybody who knows the name and value of that cookie can still use it, though. (Perhaps they pulled it out of a log months after the cookie expired; they can still set a cookie with that name and value.) You need to either track which cookies are valid server-side, or you need to include the expiry in the cookie and prevent it from being modified via some form of cryptographic integrity check, such as a digital signature or Message Authentication Code (MAC).

This is, incidentally, how JWTs work. A JWT has three parts. Two of them are data: the header (saying who issued the JWT and how long it's good for and so on) and the claims (saying who the bearer of that JWT is and what privileges they have, according to the issuer). The third part is the signature (which is often an HMAC, because they're usually shorter and cheaper to verify than public key signatures, although in some cases such signatures are more secure) which is based on a cryptographic hash of the other parts and prevents the data parts from being forged or modified without a cryptographic key that is kept secret. When you "verify" a JWT, you're performing a cryptographic operation to ensure that the JWT's signature is correct for the other parts, meaning it hasn't been tampered with.

You say "the cookie is typically the JWT itself", and that's true, but in this case "typically" obviously doesn't apply. If you're storing only part of the JWT - for example, everything except the signature - that's completely insecure; I can just forge a JWT for another user and send it to your server, and the server will think I'm that user who has authenticated and then been handed this truncated JWT as a cookie. Same deal if you're doing things like stripping off the JWT header for the cookie; the signature part is no longer valid, so you can't tell the difference between a legitimate cookie and one I made up (or edited to claim I'm some other user).

It sounds like what you're proposing doing is using the JWT from Cognito to authenticate / authorize the user, and then creating your own session token for subsequent use. This is basically how many single-sign-on (SSO) systems work; there's nothing wrong with the idea in general. However, it relies on you having a secure session token infrastructure.

There are, broadly speaking, two ways to do session tokens safely:

You issue a short-ish token (usually just a cryptographically random string) to every authenticated user, and also store the table of valid tokens (and what users they map to) server-side.

Advantage: the server always knows which tokens are valid; it can store expiry information where the user can't even see (much less edit) it and it can prematurely expire tokens (if the user logs out or requests to end other sessions).
Advantage: no long-term secret that an attacker could steal to be able to forge valid tokens.
Advantage: the only cryptographic operation is the random number generator that creates the tokens.
Disadvantage: if you run a cluster of servers, they all need to be able to check, constantly, whether the token is valid. This requires either a distributed memory cache, some tricky behavior where you bypass load-balancing to lock a user to one server, or a whole lot of database queries.
Verdict: simple, but doesn't scale well.

You create a token that contains the session details (user identity, authorization, session expiry, etc.) and use a secret cryptographic key to sign the token and prevent the user from modifying or forging it. This is how JWTs work.

Advantage: no server-side state at all. So long as every server knows the key needed to verify the tokens, the server doesn't need to remember anything about which sessions are active.
Advantage: a token can be issued by one server and used by another. They don't even need to be owned by the same entity, so long as the validating server trusts the issuing server. Asymmetric (public key) cryptography allows the issuing server to keep secret the "private key" required to create valid tokens, while any server with the corresponding "public key" can verify them.
Disadvantage: it's hard to expire a token early. There are ways to do it but they're messy and don't scale well either. Therefore, the tokens are usually short-lived, and are re-issued periodically (often via a "refresh token" of the first type, which is used rarely enough to not be a scalability problem).
Disadvantage: the signing key is the linchpin of the whole system. If an attacker obtains it, then the attacker can forge valid tokens and the server won't know the difference. Periodic rotation of the signing key can help, but even a very short compromise (the period between the signing key becoming known to the attacker, and it ceasing to be a trusted signing key) can be devastating.
Disadvantage: cryptography is hard to get right. Although this is a pretty simple cryptosystem, it's still got enough moving parts that there's a risk of somebody screwing it up. Also, there's a risk if, say, the cryptographic hash used to create the signature is broken, and somebody can create a different token body which produces the same hash. The work-around here is just to use a well-trusted implementation written and reviewed by people who know what they're doing, keep it up to date, and use modern cryptographic primitives (for example, the SHA2 or SHA3 family, rather than SHA or MD5).
Verdict: usable with every kind and scale of system, but harder to get right and more likely to fail catastrophically.

Looking just at the list of advantages and disadvantages, you might think the first approach is better, but it turns out that the scaling thing is a huge issue for many systems. The hybrid approach (short-lived type-2 access tokens plus session-lifetime type-1 refresh tokens that can be used to get a new access token) works well, at the cost of some additional complexity, but still doesn't remove the need for the signing key to be kept absolutely secret and the access tokens to be verified securely.


Could we make an impervious server with read-only software and no root access? A long time ago people talked about the Harvard architecture, which had the program separate from the data. Similarly, if the software of a server was not modifiable (burned in to a crystal or something - note: hypothetical, do not attack this premise) and it came out of the box with no root user and no way to add or change anything (except data), we would have a sort of "appliance" that worked like any other piece of familiar hardware, and could not be commandeered.

Does anyone do this now and if not, is there a technical reason why not? Basically I am proposing a throwaway device that perhaps does not even store the data in itself, but only controls access to a separate disk farm or something. If something goes wrong, you unplug it and plug a new one in and keep going, like RAID for the server itself.

This would prevent the server from executing code that was written by an attacker, that does seem like a good idea, but another problem remains.
You'll have to include some software in the beginning, when you create the server. Every piece of software has a fault somewhere, no matter how many tests you go through. If you write this software to the server and 2 months later, an exploit is found where the attacker doesn't inject code (since that is not possible by premise) but rather uses existing code in the software to break something, by sending data the coder did not expect.
Since your server code can't be changed you now have no way of applying the security patch.


List of methods in iOS that have been deprecated for security reasons? Is anybody on the nets keeping track of iOS methods that have been deprecated by Apple for security reasons? I have searched around but with no luck.

Going through all the deprecated methods and figuring out which ones have security implications would/will be a lot of work. I'm hoping this info is already being tracked elsewhere.
Thanks.

This may be of some help. http://support.apple.com/kb/HT5567

I would think this information would be in the Security Update announcement.


How does this privilege escalation vulnerability on Elastix work? Here is a privilege escalation vulnerability on Elastix:

# id
# uid=100(name) gid=101(name)
# sudo nmap --interactive

# Starting Nmap V. 4.11 ( http://www.insecure.org/nmap/ )
# Welcome to Interactive Mode -- press h <enter> for help
# nmap> !sh
# id
# uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)

How could a normal user start nmap with sudo privilege? What exactly is misconfigured here?

Source: http://seclists.org/fulldisclosure/2012/Mar/234

The misconfiguration would come from either a group, or user entry in sudoers.conf. This is the file that controls who can do what (with regards to sudo). In this instance judging by your commands (if they were not edited) the sudoers file contains an entry for the user asterisk to run the sudo command without entering a password.

Now in the case of nmap --interactive - that was removed some time ago. There was an escape trick that someone could use while in nmap to abuse the system. E.g.:

nmap> !head -n1 /etc/shadow | mail -s shadow my@emailaddr.com


Public IP Address to be tested legally? According to this question on Quora:

  Scanning a public IP address can be a cyber crime.

But there are a few public IPs that can be used for testing purposes such as

45.33.32.156 which is belong to http://scanme.nmap.org/
176.28.50.165 for http://testphp.vulnweb.com/

Is there anything else? I would like to have something in e.g. the range x.x.x.1-10.

Depends on what you want to "test"

If all you care about is port scanning, then the two above-mentioned addresses are perfectly fine. It demonstrates how nmap works, and you can use these hosts to try out some further scanning techniques (Service Detection, OS Detection, etc.)

You can also port scan some internal devices, such as:

PC
Laptop
Smart Phone
Game Console
Router (Internal & External IP)
Printer
"Smart" Devices (Fridge, TV, Lightbulb, etc.)

Since you are the owner of these devices, you can scan them freely as you want. You'd be surprized what you can discover there.

What if you want to "test" more invasively?

Port Scans are kind of a grey area, depending on the applied jurisdiction. Some consider it a crime, some don't regulate it at all. And while it may not be legal, a lot of port scans happen all the time over the internet. That doesn't make it alright of course, and you should not interpret my previous statement as "It's alright to do it". The golden rule of ethical hacking is to never attack a system you don't have permission to attack.

But what if you want to do more invasive testing? You have several options:

Install a local vulnerable system

You can install intentionally vulnerable distributions such as Metasploitable or insecure services like OWASP Juice Shop. These are designed to be learning tools for people interested in learning penetration testing. Since these run locally on your own system, you can freely test them however you want.

Use a remote vulnerable system

Services like Hack The Box offer similar vulnerable "boxes", which you can attack within the permissible parameters of their EULA. These are generally designed as explorative teaching tools, meaning you will learn new things as you try to exploit them.

Participate in a Bug Bounty program

Some companies offer bugs for vulnerabilities in their programs or services. It's possible that some company explicitly allows you to test for e.g. XSS vulnerabilities on their service. In that case, you do have explicit permission to test that.


How secure is GPG symmetric encryption? Since I am new to encryption and have recently been losing stuff, I decided to start a file that contains some passwords for online accounts and whatnot, encrypt it, back it up (and keep a single copy on Google Drive....cloud storage seems insecure to me.)

I was wondering about using GPG though.

Is the default algorithm, CAST5, sufficient? gpg -c file uses it

Is there any chance that my file could be broken by Google? It uses a long password that seems secure.

Should I add extra information throughout to act as "additional entropy"? Maybe dd if=/dev/random >> file

And the most important question...is GPG even right for this job-encrypting basic text files. Is there a better, mroe secure option, or a faster option?

CAST-5 aka CAST-128 is a fine choice of algorithm.  It probably hasn't had as much cryptanalysis as, say, AES, but there are no significant publicly-known weaknesses in the algorithm.  It's a 128-bit cipher, which is computationally infeasible to brute force, and so all of the security depends on the security of your passphrase.  GPG performs a technique known as "key stretching" (see the s2k options) to make it harder to brute force passphrases as well.

GPG is a great tool for encrypting text files -- that's basically what it's designed to do.  (Encrypt arbitrary blocks of data.)  You can use a password manager if you prefer to have your data structured/managed for you, or select something that plugs in to your browser.

  Should I add extra information throughout to act as "additional entropy"? Maybe dd if=/dev/random >> file

This won't do any good.  Modern crypto algorithms are not dependent upon any entropy present in the plaintext, but only in the key being used.  A known-plaintext attack on a cipher would render it dead from a cryptography point-of-view, so this should not be your concern.


How is Tresorit client-side encryption key stored and managed? I am using Tresorit on Mac OS X and iPhone.

When I am using it there is always applied client-side encryption before posting the file to cloud. The key used for encryption is AES-256 and CFB mode of operation is used.

But I can't figure out how is the key generated and where is stored. Also how is the key transferred or generated on iOS when you would like to access files from two different OSs.

The only information you are providing in registration is your email and password.
There is application Tresorit.app on Mac OS X where I tried to find the clien-side encryption key but with no success (there are only certificates of Tresorit and Starcom).

So how this works? Where I can find my AES-256 key?

I know this is a late answer, but might still be interesting for others:

The whole process is very well explained in the link below. When you sign in on a device for the first time it downloads your roaming profile from the Tresorit server. It then decrypts you master key from the profile using your password and the master salt (also in your profile, only part not encrypted).

https://support.tresorit.com/hc/en-us/articles/216114377-How-is-your-user-profile-handled-


Event codes for Unix I have to write alerts in SIEM Tool. Do we have any events code for Unix as we have in Windows.

If yes, where can I find that?

If not, on what basis can we write alerts for unix flavours or machines? It would be needed for auditing, application or network based alerts.

Do we have any Events code for Unix as we have in Windows.

nope. what you have is a bunch of software that writes logfiles, but these logfiles do not follow any standard.

  If Not, On what basis can we write alerts for unix flavours or machines . for Auditing,application or network based alerts.

network-based attacks are usually detected by a NIDS like snort, suricata, bro (open source) or whatever commercial IDS you use. any decent SIEM should have connectors for these kind of alert-systems.

the same applies for hostbased-intrusion with tools like OSSEC or other opens-source stuff that works on logfile-analaysis. for any serious NIDS/HIDS and SIEM you'll find connectors and ways to inject events from that system into the SIEM


Do comparative reviews of OS safety exist, which consider the code volume? I am looking for alternative OS, and security is a key concern. I am interested in reading reviews which compare or simply deal with the security merits of OS, and which moreover not only consider the aspects

is the code open source ?
what are the audit code quality mechanism in place?

but also:

how much code to audit and with potential bugs/backdoor-hidingspace exists? (the code volume).

I have attempted to find such reviews, but without any success, hence the question here

The ideal would be to have a main infrastructure of minimal, open-source code that is distributed in a secure, signed fashion, but still be able to run untrusted code. The first thing that comes to mind is something like Qubes. I don't know of a comprehensive comparison, but i do know they take their codebase paranoia extremely seriously.

  Qubes takes an approach called security by compartmentalization, which allows you to compartmentalize the various parts of your digital life into securely isolated compartments called qubes.

  This approach allows you to keep the different things you do on your computer securely separated from each other in isolated qubes so that one qube getting compromised won’t affect the others. For example, you might have one qube for visiting untrusted websites and a different qube for doing online banking. This way, if your untrusted browsing qube gets compromised by a malware-laden website, your online banking activities won’t be at risk. Similarly, if you’re concerned about malicious email attachments, Qubes can make it so that every attachment gets opened in its own single-use disposable qube. In this way, Qubes allows you to do everything on the same physical computer without having to worry about a single successful cyberattack taking down your entire digital life in one fell swoop.

alternatives:

http://www.projectatomic.io/

https://coreos.com/

http://rancher.com/rancher-os/


The directory authorities votes on what the Tor network consensus that lists all relays should look like so that a majority of the authorities need to behave badly in order to publish a malicious consensus for clients. See https://metrics.torproject.org/consensus-health.html for how the voting goes. All the private keys is not needed to win the vote and perform attacks you already mention.

You might get a more detailed answer over at the newly opened Tor Stack Exchange.


For certain URI, is it possible to log the rule violation instead of returning access deny? We have set up Modsecurity CRS with Nginx and we are in the phase of customization (or writing the exclusion rules).
We'd like to know if it is possible that modsec can only log the exception for certain URIs without adding up the score while the rest of the URIs still being protected. Or, whenever it tries to return Access Deny, it will check if it for certain URIs first. I've read a couple of tutorials and they suggest either setting detection mode or the threshold to a huge number, while we'd like to start the protection now but don't want to affect certain URIs as they are critical for business. If modsec finds rules violation for those URIs, we'd like modsec to log it only and we'll write exclusion rules after reviewing the logs.
Modsec verion: v3.0.3
Nginx version: 1.13.6

This is certainly possible, as you could have different settings per location.

According to Installing OWASP CRS:

  Once ModSecurity is compiled in you will have to specify both
  ModSecurityEnabled and ModSecurityConfig within any location block
  where you want ModSecurity enabled. An example would look similar to
  below.

location / {
    ModSecurityEnabled on;
    ModSecurityConfig modsec_includes.conf;
}

However, Nginx's blog article Compiling and Installing ModSecurity for NGINX Open Source has a bit different form for these directives, and the ability to use them directly within the server {} block:

server {
    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/main.conf;
}

You must choose those that apply to your installation, but you'll get the idea. This example is based on the latter syntax, but if you can't apply the rules directly like this, you could simply use different ModSecurityConfig files for different locations.

The detection only mode is configured with SecRuleEngine DetectionOnly.

server {
    listen 443;
    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/main.conf;

    location / {
       modsecurity_rules '
           SecRuleEngine On
       ';
    }

    location /business-critical {
       modsecurity_rules '
           SecRuleEngine DetectionOnly
       ';
    }
}

This is best to be a temporary solution for two reasons:

Your business critical URIs may also have vulnerabilities.
There will be a lot of noise in your logs from the constant automated attacks.

I'd suggest testing through every feature and acceptable use case. Then, find false positive detections by limiting the search to your own IP address. Once you know the rules that will cause problems to your application, you could disable them with SecRuleRemoveById and enable rest of the protection, e.g.

    location /business-critical {
       modsecurity_rules '
           SecRuleEngine On
           SecRuleRemoveById 941100 941120 941160 941180 949110 980130
       ';
    }


SOCKS proxy security concerns As claimed, "A socks proxy simply transfers data from a client to a server, not penetrating into this data contents (therefore it can work with HTTP, FTP, SMTP, POP3, NNTP, etc.)", I really can't buy it, can't a SOCKS proxy log data, analyze its content, redirect traffic, capture submitted forms, intercept SSL/TLS communications, "harvest" emails, or even spoof an IP address through a poisoned DNS?

I understand that SOCKS operates at lower level than HTTP proxies, and that it support authentication in its SOCKS5 version.

I found it risky to use proxies, but sometime its the most "feasible" as an exchange to privacy, when it come to region limitation and bandwidth allocation.

Can anybody clarify the above points?

A SOCKS proxy is in a position similar to a router: it sees all traffic. It is thus in ideal position to commit various felonies on your data. You should consider it as you would consider any router on the Internet (including your ISP): it fulfills a service but you do not trust it. Using an external proxy is no less risky, but no more risky either, than doing proxy-less connections(*). The short mantra is: SSL protects you, as well as it protects you over the Internet in general.

The error would be to believe that a proxy which asks for authentication somehow makes your data "secure" in some way. Don't be fooled ! The authentication is for the protection of the proxy, not yours.

A special case is proxies which claim to offer anonymity. Nothing guarantees that; that's a promise the proxy makes and you cannot enforce it. For Tor (Tor is just boosted proxying), risks of hostile proxies is mitigated by chaining them, so that your anonymity is preserved as long as at least one of the proxies is trustworthy.

Of course, if the proxy is your friend and is really trustworthy, then it can help in defeating attackers. For instance, a SOCKS proxy through a SSH connection (ssh -N -D 5000 othermachine, and set your browser to use 'localhost:5000' as SOCKS proxy) is a cheap but effective VPN for your Web-based traffic, between your machine and the network where othermachine is located (I was doing that a lot when I was working for a company which was physically on another continent).

(*) Ok, that's not entirely true. Low-grade attackers, as opposed to, say, oppressive governments, could find it uneasy to make Man-in-the-Middle attacks on your data; they would have to ressort to crude methods such as DNS poisoning. If you accept to forward all your data through the attacker's proxy, then you make the task easier for him in practice. But you should not assume that not using proxies makes you immune to low-grade attackers. Also, this does not change anything high-grade attackers who control infrastructure routers: by using their proxy, you are not giving them any power over you that they did not already possess.


Can autoplay USB stick spread virus to windows 8 or 10? Autoplay was a security hole on older versions of Windows, but can I trust newer version like Windows 8 or 10 to insert USB stick without turning autoplay off?

The difference in modern version of Windows is that Autoplay is off by default, but it is still available and can be enabled. However, if you do not know the current Autoplay configuration of a Windows machine, you should check it before inserting a suspect stick.


Missing scripts in NMAP I've just installed the latest Kali and updated everything. nmap is version 7.12.

I've noticed that smb-check-vulns.nse is not present. As far as I can tell, most other scripts I use are there but I've got an exam coming up and I don't want any bad surprises.

I tried to manually add smb-check-vulns.nse by fetching the script source from nmap.org, but that gave me some errors and the script is not running.

Was there a change that deprecated some scripts recently, or am I the only one experiencing a missing script? Is there any way to ensure I have all nmap scripts installed?

The changelog for Nmap 6.49BETA6 says:

[GH#171] smb-check-vulns has been split into:

    smb-vuln-conficker
    smb-vuln-cve2009-3103
    smb-vuln-ms06-025
    smb-vuln-ms07-029
    smb-vuln-regsvc-dos
    smb-vuln-ms08-067

The scripts now use the vulns library, and the "unsafe" script-arg has been replaced by putting the scripts into the "dos" category. [Paulino Calderon]


Intercepting proxies and web traffic interception What are intercepting proxies? How can you intercept web traffic and what are the tools for it?

Intercepting proxies are tools used to analyze, modify, and in some cases inject traffic into the normal session created between a client and server.

One common example where this is used is in testing the security of a website using a tool like Burp Suite which acts as a proxy connecting your own web-browser to it, frequently using a plugin similar to foxyproxy but this can also be done via manual configuration, then having Burp Suite initiate connections to the web server on the clients behalf.

This allows Burp Suite to control a connection that was requested by the web browser and allows for a large number of tools and testing methodologies to be inserted into the connection. It should be noted that there are some browser plugins which can perform many security tests but by utilizing the hooks to connect to a proxy it removes many of the software limitations and allows for much easier testing of the web server.

Finally it's worth mentioning that these allow for dynamic testing of the application which is very different than what you might do by simply analyzing traffic between the client and server. Likewise there are lots of other types of intercepting proxies used for other types of testing (not just for security).


Is it possible to look up all internet activity done by a MAC address, IP address, etc.? It seems like something that an average person can't do, but can some big-name companies or maybe hackers have the technology to look up all Internet activity that has been done by a certain MAC address (or other computer identifier like an IP address)?

There are a lot of variables to consider with this question, and I've ignored MAC address tracking, since it is generally fairly easy to change a MAC address anyway.

An ISP can look up what connections have been made from devices which use its network. This may be down to the page level, for HTTP connections, the site level, for HTTPS connections, or to an IP level, for things like SSH or proxied connections. It cannot generally see what happens outside of its own network, so it wouldn't see communications between an ecommerce site server and a payment provider server, even if that was triggered by an action on the network it can see - you submit login details to the shop, shop server sends stored card details to payment provider, along with total cost, provider responds to shop, shop responds to you. Only the first and last steps would be visible to the ISP.

The ISP also can't see, generally, what happens within your local network - it couldn't say which machine on your network was the original source of a request if the connection is using NAT (typical for most providers). This changes slightly with IPv6, but I'm going to ignore that for the moment!
Analytics, advertising and social network providers can see what pages a given computer has visited, based on cookies, and enhanced by IP addresses. They can only see pages which have embedded their code - in the case of Google, that's a lot of pages, since so many sites use Google Analytics - but can see down to the specific page level, even on HTTPS connections. They have no visibility of non-web activity, so can't see if a computer makes a SSH connection, unless it is to a server they control.
Theoretically, operating system vendors could see everything that a specific computer did whilst running that operating system, since all the traffic is likely to go through OS control layers. In practice, there is no evidence of this taking place, even with report-back features in some operating systems.
Similarly, theoretically, a PC manufacturer could embed a monitoring device into computers which could report back. Again, there is no evidence of this happening, and any data sent in this way would have been detected by routers.
If you are on a business network, the IT department can see pretty much everything that goes on. This may include HTTPS traffic to the page level, if they are using man-in-the-middle monitoring techniques, although these do tend to violate privacy of users, and may leave company systems open to other attacks. For business, include educational institutions, general governmental departments, and any other corporate environment.
Security agencies (e.g. NSA, GCHQ) can obtain information from ISPs, social network companies, advertising agencies, and businesses, either legally, with a warrant, or through more dubious means. They can therefore obtain pretty much any data about what an IP address has been up to. They cannot generally state that activity connected to a particular IP address was generated by a specific person (there are exceptions - if there is a video call and a target is speaking to the camera, it would be very hard to argue that it wasn't them). They also have limited ability to follow data running through secure proxies - they can see a connection was made to one, but may not always be able to see the ultimate destination of the traffic.
Hackers. I'm going to sub-divide this one:

If they can install a rootkit on your system, or your router, treat as malicious PC manufacturers. Assume they can see everything (you are probably safe if you use a live CD).
If they can install monitoring software on your system, treat as malicious OS manufacturers. Assume they can see everything from current operating system up (you are probably safe in a different OS)
If they can sniff your traffic, treat as ISP. Assume can see data to same levels as described there, but with the ability to pinpoint local machines too.
If they can hack ISP, analytics, advertising or social media providers, or business network, assume can see everything under the corresponding entry.
If they can install browser toolbars, treat as analytics provider, but with full knowledge.
If they can't install anything, can't monitor network traffic, and can't hack other system, they probably can't see anything. They can still be dangerous though.


Drupal SQLi only on login form? Recently, CVE-2014-3704 was in the news. This vulnerability allows attackers to execute SQLi without the need of being logged in.
However, I've looked to the available exploits, and I found only exploits that make use of the login form.
Does this mean that when the access to the log in field is restricted (IP white list), there is no risk (as long as they cannot access the log in form? Or is it possible to exploit this on a different Drupal component as well?

Some share of thoughts would be appreciated!

According to the Drupal advisory:

  This vulnerability can be exploited by anonymous users.

According to this answer:

  I can confirm, that this vulnerability will work with every Drupal 7.31 and lower site, doesn't matter which modules are active. Every drupal form could be used to exploit this vulnerability.


How efficient are the old-good text-image-based capthas nowdays to prove that a form has been submited by a human? With the rise of google re-Captcha that is known to be the most effective one because of the use of real images that are computational hard to get distinguished from a machine. In other words a human is easily able to distinguish a truck from a duck whilst for a comptuter is rather hard or computational expensive to do that.

But I still wonder how old good text based captcha implementations like the one that gitea uses (look image bellow) are good enough to prove that the form has been submitted by a human? Or image recognition is the most efficient nowdays that these type of caphca tests has been rendered as junk?

They're useless. Alphanumeric captchas were defeated by off-the-shelf image-recognition libraries years ago.

Even Google's implementation can be bypassed by any sufficiently motivated actor by delegating the work to a click-farm for $0.01 cent per solution. There are literally pools of people who get paid pennies to solve these all day so bot traffic can be conducted unhindered.


Store shell history in block chain Would it be possible to securely store all issued shell commands (.bash_history etc) in a block chain to prevent users from modifying their history?

I'd be interested in implementing this for several multi user systems, though I wonder why no one seems to have adopted this idea yet. Many attacks involving shell access, in some way or another, could be traced better if the command history was accurate; malevolent users could not cover up their actions, and so on.

The shell is probably the wrong place to do a logging of commands. A user could simply execute another shell without history or execute commands read from stdin without leaving a trace in the history. Thus it does not protect a lot against malevolent users.

Instead of securing the shell history one should securely log the commands executed by a user, no matter if these are executed by the shell or not. And this should be done so that the user is not able to execute any commands without trace. There is actually already an audit framework which can do this, see System Auditing in the RHEL documentation.

And while blockchain sounds like a nice  (and hype) technology: there are other technologies which provide the necessary security without all the overhead. For logging the activity of a non-privileged user it is enough to do the logging as root. In case one fears privilege escalation one can use the existing mechanisms of syslog to log to a remote server. And some syslog implementations also provide a way to sign the messages to prove their origin.


Testing for CCS Injection I'm trying to test for a CCS Injection. I have found two prevailant methods to do so

Use nmap's ssl-ccs-injection nse script
Tripwire's OpenSSL-CCS-Inject-Test

Both are pretty simple to use, however, they are giving me different results. nmap's script gives me a STATUS: Vulnerable while Tripwire's script gives me a "No need to patch" message. What do I believe/what do I do?

Many thanks for the help.

In order to exploit the vulnerablity, a MITM attacker would
  effectively do the following:

  o Wait for a new TLS connection, followed by the ClientHello
  ServerHello handshake messages.

  o Issue a CCS packet in both the directions, which causes the OpenSSL
  code to use a zero length pre master secret key. The packet is sent to
  both ends of the connection. Session Keys are derived using a zero
  length pre master secret key, and future session keys also share this
  weakness.

  o Renegotiate the handshake parameters.

  o The attacker is now able to decrypt or even modify the packets in
  transit.

  The script works by sending a 'ChangeCipherSpec' message out of order
  and checking whether the server returns an 'UNEXPECTED_MESSAGE' alert
  record or not. Since a non-patched server would simply accept this
  message, the CCS packet is sent twice, in order to force an alert from
  the server. If the alert type is different than 'UNEXPECTED_MESSAGE',
  we can conclude the server is vulnerable.

Source: https://nmap.org/nsedoc/scripts/ssl-ccs-injection.html

You can use openssl s_client in linux for sending packets to the server and confirming the vulnerability manually.

Moreover I will suggest you to use testssl.sh available on https://testssl.sh because the tool is way more comprehensive and accurate.


Is there a vulnerability in subdomain redirection, similar to Open Redirect I found a website that has the parameter post_login_redirect= I can change to any existing and non-exisiting subdomains, but there is no possibility to redirect to another domain. The redirect occurs after the user logs in.

For example:

we have sub.domain.com and we can change to anything if we respect the domain.com. so we can redirect to a.b.c.b.domain.com even if that subdomain doesn't exist, it will redirect anyway. But we can't redirect to a.hello.com

This is not an open redirect issue, because we can only redirect to subdomains that we don't own.

Is there any possibility to chain this or make this a real vulnerability?

Except for special circumstances (see below) or an especially high-security environment like online banking (then they should use a whitelist of destinations, or perhaps not redirect at all), I would say that this is not a risk worth mentioning. If you can't redirect to anything that is fully or even partially under the control of an attacker, there isn't really any risk.
There are quite a few things that might be attacked-controlled or influenced, though. Consider:

Can employees of the company request subdomains and run something insecure there?
Can you register a subdomain? (E.g. if it's a webhosting company.)
What if you enter an IP address instead of a (sub)domain? Can you format the IP like http://0x50.031101626?
Does the URL parser properly check the URL, e.g. is something like https://domain.com@hello.com recognized to be under the control of hello.com rather than domain.com?
Would switching protocols or using a different port help at all?
If desktops can be resolved with something like DESKTOP-9BA5A95.dyn.domain.com or 80-100-131-150.employees.domain.com, can employees request firewall exceptions? I.e. could someone with low privileges (the proverbial cleaning lady/man) setup a web server somewhere on one of these desktops and trick other users into using the redirect? (This sort of thing used to be more common in the past, probably almost non-existent in 2020.)
Some DNS resolvers and scummy ISPs (like the German Telekom) inject ads when a domain cannot be found. Can you redirect to a nonexistent subdomain like some-keyword.domain.com and buy an ad for some-keyword, hoping the user thinks the ad looks legitimate and clicks it?

There are quite a few options here, but some rely on other vulnerabilities being present and others won't be common or very practical.


How to secure MySQL server for the case of hardware theft I am setting up a new MySQL server in the office. The client app, connecting from the same LAN, is now in beta testing. So I can still change authentication system and other stuff there. Currently I decided to compile the string of private key into the app.

The client first provides the key and gets connected to the root account in DB. Then, a (particular) password hash is requested from the DB, based on the username inputted. If the hash is equal to the one made out of the password-box contents, the actual app starts.

I decided to encrypt all data stored there (use LVM, basically), but my boss is very concerned on the case where the server is stolen together with an employee's laptop (some nice guys have password PostIt's on screen edges).

I would be grateful for any info on:

Restricting client connections to a certain timeframe (7AM-7PM, Mon-Fri).
Restricting any connections or better, even logging in into CentOS (or any other distribution, if you have suggestions) by the location.

The only thing that came to my mind by now, is that shared printer and a small FTP for keeping scanned stuff can play a role in assuring that the server is in fact still on our network and not stolen and taken from the office. Say, I can verify the name (model) of the printer and check hash-sum of some file I quickly download from FTP.

If it is a suitable solution, please give details on how to manipulate the server security itself. Like, I can make a script that would return 1 or 0 in case of the FTP/printer requirement is met, but how do I use the result of this check?

Suggestion to your problem:

Make sure the timezone is configured correctly and that you run ntpdate/ntpd on your machine to keep the time in synch.
Apply iptables rules based on time and day.

iptables -A INPUT -m time --timestart 07:00 --timestop 19:00 --weekdays Mon,Tue,Wed,Thu,Fri -j ACCEPT

For GeoIP support with Linux netfilter see: https://daenney.github.io/2017/01/07/geoip-filtering-iptables.html

On another note I'd suggest you to enable Google Authenticator (phone/push notifications) or Yubikey integrated with PAM, to achieve a multi-factor authentication scheme.


NFC Android (Ntag213 vs Ultralight C) I have an (university) project where I basically write and read text out of NFC Tags with Android devices in order to store one's balance in the card (wich can be used on the cafeteria, for example).

Right now, I'm using Ntag213 doing the below code:

ndef.connect();
NdefRecord mimeRecord = NdefRecord.createMime("text/plain", messageEncrypted.getBytes(Charset.forName("US-ASCII")));
ndef.writeNdefMessage(new NdefMessage(mimeRecord));
ndef.close();

As you can notice, I'm using application level encryption to encrypt the message (messageEncrypted) before writing it to the tag (AES-256 encrypt with 'com.scottyab:aescrypt:0.0.1' library - with a very big password key which is also combined with each tag UUID as part of it).

So far so good - Only I can understand the data on the tags.

On my research, I've found that when it comes to security Ultralight C > Ntag213.

**I know both tags have limited space but it is more than enough for me.

Question 1) When using application level encryption, why (is it?) is Ultralight C safer then Ntag213?

Question 2) I'm pretty sure I can guarantee security using AES encryption on application layer, but I don't want people (besides me) messing with the stored data (formatting tag or writing info there - even if I can dettect it). I see that the only way of preventing that (please, correct me if I'm wrong) is to set a password for the tag. However, both Ntag213 and Ultralight C have only an 32 bit password. Is it good enough? Is there another way of preventing someone (besides me) writing data?

Question 3) Which other security measures can I use on such tags to enforce security (tag and application layer)? I see that Ultralight C has 3DES Authentication, but I haven't find an example for Android so far.

Question 4) When you compare tag security (Mifare Desfire > Ultralight > Ntag213 > Mifare Classic), what is really being compared? The ease of one cracking the (native tag's) encryption or the ease of one store (anything) on the tag without permission ?

Question 5) I see a bunch of other techs (Mifare Desfire, ICODE SLIX, Infineon Cipurse) that are more secure, which makes me wonder if the tech I'm using (Ntag213 or Ultralight C) is good enough for storing someones balance. Would you (and that's a personal opinion) say that Ntag213 with application level encryption and 32 bit password good enough for this type of application? And how long would it take someone to actually break its security?

With your code, an attacker will not be able to forge a valid message for your system. Yet she can still copy a (valid) message you've created and paste it on any other tag or restore to a previous state.

This means that this is possible:

Restore the account balance (if it's what stored on the tag) to what was before the purchase (simply by copy the tag before purchase and restore after purchase)
Share with someone else account (if you leave your tag unattended, some attacker can copy it and paste it on another tag, impersonnating you for further purchase).

Please notice that even if you are checking the balance online with a database (per-tag) to limit case 1, you can't prevent case 2 with your scheme.

The 32bits password protection only prevents from modifying the content of the tag unless you know the password (since I doubt you'll use the password to set a "no-access" zone), but anyone with a simple $100 tool can capture the password when operating a valid tag since it's transmitted in clear (MITM here), so it's useless as I understand your need.

To prevent the kind of abuse above, you need a way that:

Does not transmit the password/secret key in clear text
Create a likely random (different for each access) session key for ensuring the reader and the tag are what they pretend
Use that session key to access / modify data on the tag

This is only possible with Mifare Ultralight C (or DESFire) tags (don't use Mifare Classic as their crypto is broken).

Typically, with such tag, you'll use the tag unique identifier to create a per-tag, per-sytem secret key. With this key, you'll authenticate with a block on the tag and store the balance/message encrypted with another key you're deriving from the tag UID. You should also rotate the keys, if possible after each authentication.

If authentication is valid, you're sure that the tag isn't cloned, and wasn't restored from a previous state.

So to make a clear diagram of the process:

  let M = message to store on tag
  let transaction = the current transaction counter you need to store in a database
  let Secret1 = some secret random value for your system (16 bytes for 3DES key). Depending on your security need, you might need to derive this secret from the reader's unique identifier.
  let Secret2 = some another secret random value for your system (16 bytes for AES key)

  When a tag is enrolled:
    let UID = tag UID
    transaction = 0
    let authKey = Hash(UID, Secret1, transaction)
    let msgKey = AES_CTR(M, Hash(UID, Secret2, transaction))
    change KeyA from default to authKey
    authenticate with authKey on some sector
    write msgKey
    store (UID, transaction) in your database

  When the tag is used:
    let UID = tag UID
    let authKey = Hash(UID, Secret1, transaction)
    authenticate with authKey on same sector
    if (authencation failed) reject tag or kill it, exit
    read msgKey from the sector's data
    extract M = AES_CTR(msgKey, Hash(UID, Secret2, transaction))
    if (M isn't good) reject tag or kill it, exit
    Perform your system's intended action, this gives M'
    increment transaction
    compute msgKey = AES_CTR(M', Hash(UID, Secret2, transaction))
    write msgKey to sector
    compute authKey = Hash(UID, Secret1, transaction)
    change authentication's key with new authKey
    update database's transaction count.

If you don't have a database (on the reader, or if the system is not online), you can't prevent tag copy and restore since the attacker could use a NFC tool to emulate a Ultralight C card and capture the content of the block when enrolling (even through they can't understand what's inside). This is high tech so depending on the value of the assets you can to protect, it might not make sense.

There is some feature with Mifare where you can store a value in a block and you can instruct the tag to increment or decrement it if you have the correct key.
It's trivial to implement this with the above pseudo-code, but this only work if the tag is storing a balance (understand: not for a message).

Now that you've the overview, let's answer your questions:

Ultralight C allow authentication, thus preventing MITM capture of password with a NFC probe (if used, obviously, else there's no advantage)
Password is moot. Unless you can control all your readers, that is, place the tag in a sliding tray, and slide it so it's read inside the machine with no space around for electronic gizmo, it's useless.
Authentication is required. Without a way to derive a secret session key, there is no protection from a MITM. For android, I don't know.
It's like comparing a truck with a transparent plastic bag. Both can store apples. Yet, the former is more expensive but you can do more things with it, like putting more stuff in it, locking the doors, etc... If you don't care about people seeing the apples and adding/removing them, use the plastic bag, it's cheaper.
There is no real advantage for your system to use DESFire or ICode here. You actually don't need additional storage space, and 3DES is secure enough to protect a cafeteria balance here. There is no economical sense to pay hundred if not thousand of dollars of computing power to try to break the $20 balance on the student cafeteria's account.

From a usability point of view, you can use an Android phone as a ISO14443-4 NFC tag (with random UID, so my scheme above needs to be modified).
DESFire is also ISO14443-4 compliant so if you go the Android's way of doing NFC, you can still sell and use DESFire tag for those without such phone & function.

Again, this requires a lot of development to get right, and I can't tell if it makes sense for you compared to a relatively simple Ultralight C system or a web based application for paying.


Securing an API for mobile access I've built a nice REST/JSON API that is used by other companies (our clients) as a B2B service. Each of our clients has a username/password pair, and we also do HTTPS and validate the source IP of requests to service. Service usage costs money, and client is billed monthly for his usage of service.

Now, some of clients are building mobile applications that they hand out to their users (B2C - end users). Not all of these end users of our service have servers and they wish to use service directly from the smartphone (which technically isn't big deal being JSON/REST).

The problem is I'm not sure how to protect the service against fraud. What will prevent a third party developer to disassemble one of client's mobile application and copy their username/password/whatever security credentials and use that in his application? That would allow him to consume the service and charge the usage to one of our legit clients!

I'm pretty sure there is no perfect crypto solution to this problem unless end users are mandated to authenticate to some server. But that is not always the case.

As a last resort I guess I can distribute an obfuscated library for Android / IPhone, which would at least give the illusion of security...

EDIT (clarification):

Let me try to simplify the scenario.

I have an un-hackable web server which serves out a JSON REST API.
Mobile clients access my API directly. Their IPs cannot be validated. They are running a standard OS (Android / IOS).
There are no other servers involved.
I cannot access the phones' IMEI (it is considered private), nor would this help me because I don't know the end users.
There are several such legal mobile applications, developed by different companies that access our API.
Current security (username/password) is easily hackable by rogue company. Said rogue company disassembles a legit mobile application and copies the username/password to their illegal application. They distribute this application and profit (API usage is charged to the company from which they stole the credentials).

Can this be stopped?

Your question is "Can this be stopped?", but I get the feeling that anything significant about the system can't/won't really be changed.

If I understand correctly, you are asking (simplified):

  I have many clients sharing the same username and password. Can I stop misuse?

The answer to that is no. You must decide if you can afford to ignore the problem, or implement correct solutions.

If you really want to do this properly, look into implementing something like OAuth, so you can properly distribute separate auth tokens for end users, link them to your clients for billing, revoke access, etc.

--

The least you should do is allow your clients (the companies) to opt into using a better auth scheme. So, for example, you create an API for them to request (and revoke) separate access tokens for their end-users.

Company A requests token from their servers (this is initiated by their app telling them "give me a token")
You return token N, record what company it's attached to
If Company A-s app connects to your service, it sends the token N, and not username/password
Company A can tell your service "revoke token N", and futher requests with that token will not be served by your service. But, if a token is revoked, it won't render all client apps unusable.

If a company does not want to do this, they can still continue connecting using their username/password, but they would be completely responsible for all resulting usage.

The point is that you can't really hold your clients accountable for leaking credentials (something that is impossible to do in a mobile app scenario) if they have no other way to use the service.


PCI DSS minimum password strength equivalent in passphrase The PCI DSS requirement 8.2.3 says:

Passwords/passphrases must meet the following:

Require a minimum length of at least seven characters.
Contain both numeric and alphabetic characters.

Alternatively, the passwords/ passphrases must
have complexity and strength at least equivalent to the parameters
specified above.

I would like to define my policy that user should use passphrases instead of passwords with minimum length of 15 characters, without requiring both numeric and alphabetic characters in the passphrases.
Is this equivalent to what PCI DSS requires?
What is the metric of password/passphrase strength and how to compute it?

There's no guarantee that your QSA or other auditor will accept any answer offered here, but generally if you can justify your choices you can improve the odds that they will.  So I'll provide the best argument that I can.

A 7 character password randomly generated from lowercase alphabetic, uppercase alphabetic, and numeric characters offers 62^7, or around 3,521,614,606,208, possible combinations.  This also converts to around 42 bits of possibilities.  I'm erring on the conservative side of saying alphabetic character case matters (e.g. uppercase and lowercase are different) even though the standard doesn't.

So what I would do in your situation is calculate the length needed to provide the equivalent number of possible random passwords when only using lowercase letters.  That's 26^X ≥ 3.5 trillion, and X works out to be a minimum of 9 characters of length.  If you go with your goal of a minimum length of 15 characters then you'll be at 70 bits of strength, which is a substantial improvement over the original 42 bits.

These numbers do assume we're talking about random passwords to offer this level of strength, which isn't typical of most environments.  Most policies like this will still have users choosing passwords like "Muffins19" or passphrases like "Ilovemydogmuffins".  It's harder to make a strength comparison between passwords and passphrases in this reality, so I'd suggest avoiding it.  But you can, at the least, encourage good passphrase construction practices by providing users with a password manager or other software to generate random passphrases for them.


Should reverse connections be used to bypass NATs? I'm planning on doing a demonstration on how remote administrative tools work for my schools computer security club. I plan on writing a RAT in C++ and demonstrating/explaining how it works.  I ran into the issue of dealing with computers behind a NAT, but came up with my own solution.  I decided to make the victim act as a client and the attacker act as a server.  That way, only the attacker needs to make changes in their NAT to establish a connection.  Is this an appropriate way of bypassing the victim's NAT? I have heard of reverse connections being used to bypass victim NATs, but my solution seems to be much simpler. Are there any benefits in sing a reverse connection opposed to my method?

Having the client connect is the standard way of dealing with NATted connections. It can  also known as a 'Reverse Shell'.

BTW, I know you probably want to write your own RAT, but Metasploit might be a very effective demonstration ....


How is it possible for a USB device posing as a keyboard to auto-run a script without user input? I know the "USB Rubber Ducky" pretends to be a keyboard toward the OS, but I still don't understand how he can launch a script...

Normal keyboard can't just initiate keypress by itself right? Or maybe a special kind of driver is required?

When you press a key on a normal keyboard, the keyboard sends a message to the computer over USB that a key is pressed. A BadUSB device can send that same message. Instead of waiting for a keypress, it sends a couple of these messages after it has been plugged in.

So a BadUSB device doesn't just immitate a keyboard, it immitates a keyboard that has certain keys pressed in a certain order. The attacker can program a microcontroller with USB port to behave as a keyboard and press some keys after some time.


Is the lack of https reason enough to abort form submission? Preamble: Am in awe about the quality of both questions and answers on https / SSL on this site. My humble question below pales in comparison.

Both on professional and amateur websites I've encountered the following phenomenon, when trying to contact - that is, write to - the website's owner:

Rather than providing a straightforward contact@us.com email address, a form will be offered instead. Usually this form requires submitting at least two fields: your email address and your message. - Personally, I much prefer plain email, as this feels safer and more secure. If the form itself is both presented and submitted in https, I might be more willing to submit (true, non-fake) data.

Now I've come across a careers portal used by a number of companies which confronts applicant with a form in *.aspx and standard http (not https). The former already makes me uncomfortable, as I (wrongly?) perceive *.aspx to be an old/outdated Microsoft language. The latter, however, is the ultimate trust-breaker for me (lack of https).

This form asks applicants to submit personal details and to upload their CV as *.pdf.

My assessment of the careers portal: no evil intent but not up to scratch regarding internet security and (protection of) data privacy.

My question:

Is the lack of https reason enough to abort form submission?

Corollary:

Would you consider private data submitted via said form to be effectively "public"? Only because someone (with evil intent) could have intercepted the unencrypted form submission, does this already mean that someone actually has?

A first comment is that email is not secure anyway. Maybe it "feels" safer, but it actually is not. Nowadays, many mail relay systems will try, opportunistically, to activate some SSL when the mail hops from server to server. However, on a failure to establish the said SSL, the same servers will automatically degrade to non-SSL mode and send the email as cleartext; a consequence is that an attacker intent on eavesdropping on emails as they flow will not find it too hard to do: it just is a matter of sending the right fake packet at the right point to make the SSL fails, and force the machines to fallback to non-SSL mode.

Moreover, when servers exchange emails, they usually store a local copy on a physical medium. That's part of the SMTP protocol. In older days, reliability of emails was taken seriously, so the protocol mandates that a receiving server is not allowed to acknowledge reception of an email until it has committed it to a physical medium which would resist a power shortage (in programming terms, this means that the email was written to a file and a call to fsync() was made to ensure that the data is not merely cached in RAM).

The end result is that an email containing "personal details":

may be intercepted and spied upon by industrious attackers (rumour has it that intelligence agencies do it on a regular basis, which makes sense because that's what they are paid for -- but they most probably do it by making deals with the mail relay system owners, i.e. ISP);
will leave traces in many systems that you don't know, ready to be revealed by malice or incompetence of people working in network organizations that you don't know of;

from which we conclude that sending the said details over plain HTTP may be a better deal in the long run. At least, HTTP traffic goes through routers which do not have a legitimate reason to store the packets on hard disks, and indeed honest routers will not indulge in such leaking.

Now a more important point is that HTTP, HTTPS, email... are just for data in transit. If you fear for the privacy of your personal data, then your biggest worry should not be that transfer operation. The real issue is that you are, by definition, sending your CV to some hiring agency that you don't know. You cannot be sure that they will keep it in a secure place and take care of it. Actually, given the average level of security awareness, it is a rather safe bet that your CV will be put on some hackable server, copied into multiple places, exchanged by emails and thus copied into multiple mailboxes of many people, and probably printed two or three times with copies ending up in totally non-secured dumpsters.

In that sense, the lack of HTTPS is not a good reason to abort the sending process, because HTTPS would not noticeably improve the overall picture anyway.

A more practical strategy is to consider that the "personal details" you put in your CV are not, in fact, private data. These will be shared with several (many) prospective employers anyway; a secret which is shared with many people is no longer a secret. Just accept it; review your CV and what you input in the form under the basis that it won't be private. In any case, people who really want to know your name, date of birth and list of diplomas already know them (for instance, it makes no sense for me to hide my birth date, since it appears in at least two places in the Journal Officiel, the official publication place for publishing laws and decrees in France). Also, 500 million people reveal a lot more about their lives on Facebook, and this (to my darwinian dismay) has not proved utterly deleterious to their well-being.

The best that you can hope to achieve is to avoid your personal details to be harvested automatically by mindless Web crawlers. For that, email, HTTP and HTTPS are all good enough -- and irrelevant.


What are the advantages and disadvantages of different types of motion sensors? I understand there are a number of different motion sensor technologies out there, including Active Infrared (AIR), Passive Infrared (PIR), Microwave and Ultrasonic motion sensors.

I would like to know what the advantages and disadvantages of these different types of motion sensors are and what (if any) vulnerabilities exist in them.

Additionally, have I overlooked any other similar motion sensing devices?

Edit: just to clarify, human based motion sensors is what im interested in. Practical, non-theoretical technologies. This question isn't to do with vibration sensors, glass break sensors etc

Edit: To limit the scope somewhat, lets stick to more common types of motion sensors rather than exotic situation specific types?

Good answer @Adnan!

I am not sure what you are limiting your "motion sensor" question two, and his answer covered the common ones you find in typical systems. A few others, though to consider:

Active Fiber Optic - These typically are found in high-end perimeter barrier systems (like airport fences) and are used to detect motion and vibrations along the barrier.
Active Sonic - you have both ultra-sonic, as you noted, as well as sub-sonic. I won't get into the latter as it is a bit more exotic and only used for sensing in certain environments. These are of course active technologies - i.e., they send out a wave form and interpret it.
Active Tomographic - This is a radio wave, active sensing technology that can actually sense through walls and other obstructions. Your microwave would fall under this, and is just one type. The body scanners used at airports are even a higher frequency and are another type.
What Adnan referred to as Piezoelectric, is actually a generalized category of Vibration. These sensors can be piezoelectric, but can also be a wide range of other configurations: simple contact, spring based, ... Mercury switches are often used in these. Interestingly, due to the very small, easy to conceal, and nearly unimaginable number of configurations you can put these puppies in - these are often the hardest to take down if you are taking down a sensor. Good ones, even the slightest vibration beyond the norm for the environment create an alarm. So most often you have to identify the configuration of vibration sensors in the facility and create a vibration sensor alarm storm and get them cut off. But I digress.
Passive Electro-magnetic field sensors - These are out there, I have not run across many.
Passive chemical sensors (aka Electronic Nose) - Again these are out there, mostly in handheld units to do things like drug scans. However, they could be deployed in sensing environments to detect and screen for humans (like consider you are in a far off country hunting for a bad guy who is in the boondocks and you need to scan a trail that is used by both animals and humans).
Passive audio/acoustic sensors - these are emerging and actually are now going to be able to create 3D images of environments they sense. For instance, law enforcement can now deploy systems in hostile environments that can pinpoint to inches where a sniper is shooting from by the noise of the shot.
Passive pressure wave sensors - these could sense air pressure, water pressure, etc. As a person walks through a room they change the air flow and pressure wave and it is detectable. Again not in production environments but available.
I will also mention there are some very exotic, albeit non-production sensing technologies. I once saw a partial demonstration of what was called a Quantum Sensor. The theory was that space time has this weird 4th dimension "trail" that tapers off endlessly and with the right power equipment you can sense that trail forwards or backwards (like ripples in a pond after you drop a rock in it). The demonstration showed a very brief, but limited "hindsight", but never foresight - which of course you would need for "sensing". Of course it was very bulky equipment as well - so don't go looking for it in your average ADT security system anytime soon. But there is a lot of stuff like this that is going on all the time out there.


How to stop programs like airodump-ng from seing my client's MAC ID and sending deauth packets? I'm quite familiar on the aircrack-ng suite and I was wondering if there is a way to stop airodump-ng mon0 from seeing my client's MAC IDs? This is very sensitive information a program can get without even being connected to the AP. How is this possible exactly for the software to find without being connected?

On the second part (a very irritating fact) people use the macchanger -r or -m mon0 command to spoof their MAC making it nearly impossible to track in wireshark or anything, but the router sees right past the faked MAC and shows the actual even when spoofed. Why is that and could an attacker hide a real MAC when connecting to a wireless access point?

Lastly how can I stop or prevent (make it harder) to execute a (DDoS) deauth packets? aireplay-ng -0 -0 -a [AP_MAC] -c [CLIENT_MAC] --ignore-negative-one mon0 This command can cause serious problems with denial of service on clients.

I have heard a couple things about changing the channel to something high but it gets into legal issues and other things with antennas.

For the first question, your MAC address is simply not generally considered sensitive information; protocols are not designed to protect it. MAC addresses are used to let multiple devices share a physical link; packets have a source MAC and destination MAC, so that everyone but the destination knows they can ignore the packet and the destination knows which device they're talking to. The addresses are unencrypted because that's how your card knows what packets to process. WPA2 could theoretically have been designed so that it used special tokens for this purpose, but it's not clear what the point would be, because MACs aren't considered secret.

For question 2, I'm not sure the router is "seeing past" it. You can change your MAC address. It's something in firmware; on many cards, you can very easily change what the card thinks its MAC address is. There's no such thing as the "real" address; you can change the address, and that is the new real address of the device. Maybe you're seeing older log entries, or you didn't spoof it correctly, because there is in fact no general way to detect a "spoofed" MAC. An attacker can set their MAC to anything they want, and that is their new actual MAC address.

For 3, you should look into 802.11w. This is a fairly recent extension to the 802.11 standard that adds authentication and encryption to management frames (including deauth frames), which prevents deauth attacks. I think Linux and Windows both support it in general; whether or not your access point supports it is something I do not know, but you should look into.

Changing the wireless channel is not a good option, but 802.11w is a very good option to prevent deauth attacks.


Safe to sell used Android-phone without doing factory reset I've got an Android One-unit with Android 10. However it refuses to boot and I've decided to get rid of it and I think I get get some money by selling a broken phone online. However since it refuses to boot I can not perform a factory reset or similair procedures. Is is safe to sell it (assuming the person buying fixes it and boots it) or can personal data get in the wrong hands?

Some information:

I have not changed the encryption settings, so I think it's encrypted by default
I got two factor authentication turned on on my Google account and removed the device from my "trusted devices"
I have screen-lock turned on with pattern needed to unlock it.

Greed.

You have to see which you value more, peace of mind vs the scrap money you get selling a phone that is clearly faulty & close to unusable

Retrieving data from a locked/faulty phone is definitely a thing, it is a craft people possess, it is a possibility which you have to face, and you can't simply rely on us to assure you that the possibility is close to zero.

I honestly would value privacy & data-security over extra pocket-change any day of the week. I hope you can see where I am coming from, it's just not worth it.


Phishing: allow # in user provided redirect URL? I am currently working on an application that requires authentication for some pages. In order to be nice to our users we provide the ability to specify a redirect url to which the user is returned after logging in.

In order to avoid the open redirect vulnerability we want to make sure this URL is internal.

Right now we do the following:

Disallow any strings with characters other than a-z0-9/=._-
Always prepend our full base url (https://www.example.com/) before the user provided content. So even if the user sends us https://www.evil.com and it wouldn't already be blocked by step 1 it will end up as Location: https://www.example.com/https://www.evil.com.

However due to required frontend functionality we would also like to include # as a whitelisted character in step 1.

An example would thus be:

Location: https://www.example.com/totally-relative-url#magic-that-leads-to-external-redirect.

Does this open up any possibilities for open redirects?

The # in a URI denotes a fragment identifier. This is not sent to the server, and therefore cannot be used to cause a redirect without client-side help.

It should be safe to send back to a user, I would be more concerned with the rest of the URL than with the fragment.


Is it safe to store 2FA tokens together with passwords in 1password? I'm using 1password and I've seen 1password allows you to store 2FA tokens in the same place where you store the password.

I don't like the idea of having everything in the same place as if someone steal my 1password password it could access to my account and get both password and security tokens. Actually, I'm using the Google Auth for the 2FA and 1password for the passwords.

Is a good idea to keep them separated to increase security? Does it make any sense?

I work for 1Password, and I wrote exactly about this question when we introduced the feature.

The answer depends on what security properties you actually want from time-based one time passwords (TOTP). The "second factorness" of TOTP one of several security properties it offers, and it may be the least important in many cases. Don't get led astray that this all goes under the term "2FA", as if that is the only security benefit you get from these schemes.

Security benefits of TOTP (contrasted with typical password use)

So I am going to list a few of the security properties you get with TOTP and contrast them with typical password use.

Long term secret isn't transmitted during authentication. With TOTP get a long term secret that is only transmitted (typically the QR code), when you enroll. The long term secret is not transmitted when it is actually used. (This is unlike typical password usage where the password is transmitted over the net, and so depends on other protections, such as TLS). This also means that the long term secret can't be phished (although the numeric codes can be.)
Long term secret is unguessable. The long term secret is generated by the server when you first enroll, and so it is generated up to the service's standards of randomness. Again, this is unlike typical password use with human created passwords.
Long term secret is unique. You will not end up reusing the same TOTP long term secret across various services. Again, this is unlike typical password use, where people reuse passwords.
Oh yeah. And you put the long term secret on "something you have", if for some reason that is important to you.

In most cases where TOTP is deployed, it is done so because of properties #2 (unguessability) and #3 (uniqueness). Indeed, when Dropbox first introduced TOTP on their services, they spelled out their reasons as helping protect users who were reusing passwords.

After the uniqueness and unguessability of the long term secrets, the next most important benefit (for most people) is that the long term secret isn't transmitted. This makes it harder to capture on a compromised network.

Probably the least important of the security properties that TOTP gives us is the second factorness. I'm not saying that there is no benefit to it, but for the cases that most people are using TOTP, it is probably the least important.

Contrasting with using a password manager well.

In the above I listed four security properties of TOTP and contrasted them with typical password use. But now let's consider someone who is using a password manager to its full potential. If you are using a password manager well for some site or service4, you will have randomly generated (and so unguessable) password for that site and you will have unique password for that site. And so the use of TOTP doesn't really add a great deal in terms of those two security properties.

If we look at property #1 (long term secret not transmitted), TOTP still offer some additional security, even if you are using a password manager. However, using a password manager does reduce the chance of getting phished, and so the gain of TOTP, while real, is not as great as it would be for someone not using a password manager.

The only thing left is #4. If the two factorness really is why you value TOTP, then don't keep the long term secret in 1Password. But for most people, the value of TOTP comes from having a strong and unique long term secret that is never transmitted.

Look at the actual security properties

I recommend that you evaluate what you really get out of TOTP (instead of getting caught up in the whole 2FA rhetoric), and then consider the tradeoffs. I'll bet that if things like TOTP where called "Unique Secret Authentication" instead of "Two Factor Authentication" the question would never have come up.


Tips for a secure iptables config to defend from attacks. (client side!) Own examples:

###############
# KERNEL PARAMETER CONFIGURATION

# PREVENT YOU SYSTEM FROM ANSWERING ICMP ECHO REQUESTS
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

# DROP ICMP ECHO-REQUEST MESSAGES SENT TO BROADCAST OR MULTICAST ADDRESSES
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# DONT ACCEPT ICMP REDIRECT MESSAGES
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

# DONT SEND ICMP REDIRECT MESSAGES
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

# DROP SOURCE ROUTED PACKETS
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

# ENABLE TCP SYN COOKIE PROTECTION FROM SYN FLOODS
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# ENABLE SOURCE ADDRESS SPOOFING PROTECTION
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

# LOG PACKETS WITH IMPOSSIBLE ADDRESSES (DUE TO WRONG ROUTES) ON YOUR NETWORK
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

# DISABLE IPV4 FORWARDING
echo 0 > /proc/sys/net/ipv4/ip_forward

###############
# INPUT

# DROP INVALID
$IPTABLES -A INPUT -m state --state INVALID -j DROP

# ALLOW ONLY ESTABLISHED, RELATED
$IPTABLES -A INPUT -p tcp -i $PUBIF -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -p udp -i $PUBIF -m state --state ESTABLISHED,RELATED -j ACCEPT

# DROP INVALID SYN PACKETS
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

# MAKE SURE NEW INCOMING TCP CONNECTIONS ARE SYN PACKETS; OTHERWISE WE NEED TO DROP THEM
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

# DROP PACKETS WITH INCOMING FRAGMENTS. THIS ATTACK RESULT INTO LINUX SERVER PANIC SUCH DATA LOSS
$IPTABLES -A INPUT -f -j DROP

# DROP INCOMING MALFORMED XMAS PACKETS
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -j DROP

# DROP INCOMING MALFORMED NULL PACKETS
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

###############
# OUTPUT

# DROP INVALID
$IPTABLES -A OUTPUT -m state --state INVALID -j DROP

# DROP INVALID SYN PACKETS
$IPTABLES -A OUTPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP
$IPTABLES -A OUTPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
$IPTABLES -A OUTPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

# MAKE SURE NEW OUTGOING TCP CONNECTIONS ARE SYN PACKETS; OTHERWISE WE NEED TO DROP THEM
$IPTABLES -A OUTPUT -p tcp ! --syn -m state --state NEW -j DROP

# DROP PACKETS WITH OUTGOING FRAGMENTS. THIS ATTACK RESULT INTO LINUX SERVER PANIC SUCH DATA LOSS
$IPTABLES -A OUTPUT -f -j DROP

# DROP OUTGOING MALFORMED XMAS PACKETS
$IPTABLES -A OUTPUT -p tcp --tcp-flags ALL ALL -j DROP

# DROP OUTGOING MALFORMED NULL PACKETS
$IPTABLES -A OUTPUT -p tcp --tcp-flags ALL NONE -j DROP

Can we gather more great iptables related ideas to protect clients from attacks? E.g.: an Ubuntu 11.04 Desktop PC's "defend from attacks" ~kind rules.

Thank you!

p.s.: of course:

$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP

p.s.2: both on IPv4 and IPv6!

p.s.3: I don't need rules like: only allow UDP and TCP on port 53 outbound, I just want "defending" rules from e.g.: portscanning, attacks, etc.

p.s.4: The PC is behind a router/NAT or connected "directly to the internet".

I realize there are different opinions, but one major attitude of people who really know about networking and security is that most of these iptables/sysctl rules are redundant, if not damaging to you and the network. Some will aggressively criticize you for breaking with standard behavior without reason. Some examples:

The standard TCP/IP behavior is to REJECT so that the peer gets some hint on what is going on. Maybe someone just typed a URL wrong or your admin is counting the hosts or somebody wants to connect to your gaming server but typed the wrong port. With DROP they only get obscure and annoying timeouts.
There is no need to drop invalid or malformed packets, all of these attacks are a decade old. The Linux kernel devs are much more up to date than you concerning which kind of packets are valid and which not. "What about future flaws", some might argue. Well, how do you know the future flaw will be in the TCP handler and not in the iptables TCP parser?
Most of the sysctl settings are default. If they are not, there is usually a reason. Eg, why disable sending redirects? I find it very useful to be informed by a peer that my routing is bad,  even if I would never react("accept_redirects", default=0) automatically.
With your log_martians and other logging rules I hope you also have a quota on /var/log, or it will be big fun to remotely fill your disk, usually killing your services/apps. In addition, you should use a rate limit for the logging or someone might fill the quota to prevent you from  seeing the SSH password bruteforce attempts in auth.log, or other stuff. Are you actually reading those logs on a desktop? I recommend logcheck.
You appear to block ICMP. Apart from the mentioned DHCP issue, this also prevents PMTU discovery. Without PMTUD, you will get strange behavior when you use the system in places with DSL connection or other network settings. Some packets will just be dropped and nobody tells you why.
Filtering outbound packets is kind of obscure. Do you not trust yourself? You should generally not run any programs you cannot trust. Commodity operating systems are mostly incapable of isolating these programs from eavesdropping or even manipulating other program's data (e.g., cache timing attacks)
You require NEW packets to have SYN. This will break if a TCP connection is continued after the respective state in iptables already timed out. Not sure what the default timeouts are, but some netfilter guy warned about it.

So, when should a desktop have a firewall?

If there is a specific attack in the news that your current OS or servers are vulnerable to, and one of the recommended quick fixes is a firewall rule.
You have to run certain services that do not allow secure configuration. Most do, and the rest is best replaced by secure alternatives.
You have more complex networks with several VMs and/or interfaces on your desktop.

The first and foremost tool for your network security is the system update. Secondly, there is netstat and nmap, which you should use to find and confirm what services you are running. Then just disable those you don't need or confine them to 127.0.0.1.

Bonus if you read this far: Packets are either ESTABLISHED,RELATED or NEW, everything else you drop. You also drop NEW unless only SYN is set. Since ESTABLISHED,RELATED seems to check flags, this makes all of the --tcp-flags rules and also the -f rule redundant. Same for OUTPUT, but since no packets are ACCEPTed for OUTPUT anyhow, that probably doesn't matter.


Is it safe to view a file on Google Drive? My laptop got infected with a virus. It was "cleaned" by a professional but I am now reluctant to transfer files I had on my laptop to other computers.
I have plenty of images, MP4s, Word, PowerPoint and PDF documents that I would rather not nuke from orbit. Those are the only files that I would like to save (nothing executable and no programs).
Can I safely view these types of files on a Google Drive (without downloading them) from an uninfected laptop or is it best to use a Chromebook?

Let's unpack this:
"... Can I safely view these types of files on a google drive (without downloading them)..."
When you view or edit a remote file, you are downloading it. You can see it only because it's on your computer. Depending on circumstances it may only be in memory, it may be written to a temp file, it may be in chunks if the file is exceptionally large, but it's on your computer.
"... images, mp4s, word, PowerPoints and pdf documents ... nothing executable and no programs ..."
Images like JPGs or videos like MP4s are not going to carry executable malware outside of torturous logic involving steg and third party executable malware. There have been some extremely rare exploits against graphic driver flaws in the past but the odds of encountering that are just about zero.
However there are a number of file types that are executable that might not seem like it and can carry malware . The old Windows ".wmf" graphic file contains an executable capability. So too might all Windows Office files like PowerPoint. Adobe PDF, while really convenient, has a very long history of many and continuing security issues with dangerous executable capabilities, that's why there's concerted effort industry wide to stop using PDF.
"...Can I safely view these types of files ... from an uninfected laptop or is best to use a Chromebook?"
I'm guessing you are referring to using a different operating system than Windows, under the assumption of Windows only malware? Using a different operating system will help provide a buffer, but cross platform malware is not unusual in scriptable mechanisms such as MS Office and PDF's.
How likely is it that you may encounter these types of malware I can't say. The safest way to handle it is to use a non-persistent OS that can't be infected past a power cycle. (Yes there are extremes of BIOS/GraphicCard/etc modifications but it's not a significant concern.)


Forgetting passwords typed in too frequently It has happened to me several times that I've become so used to typing in a password I can't consciously remember it and it's purely muscle memory. This is particularly true with complex passwords that don't follow a pattern. It's a problem because if I'm using a different keyboard or am in a different environment I forget the password. Is there anything that can be done to fix this? It's really annoying, it's like having tied shoe lace so many times I don't really think of the steps involved.

I do use a password manager and that's the password I forget.

A method can be to subvocalize the password when you type it; that is, you go through the physiological motions of spelling it, letter by letter, except that you don't open your mouth or move your lips while doing so. You just fool your brain into thinking that it did it. The point here is to store an "extra copy" of the password in your brain: you will have it as "muscle memory" but also in your speech module.

(Subvocalizing can be an impediment -- some people cannot read without subvocalizing, and that makes them slow readers, which is inconvenient for studies which involves reading a lot, such as physicians and historians; this is not correlated with intelligence. However, in this case, controlled subvocalizing can help.)

Or simply write it down on a paper that you keep in your wallet; you already maintain strong physical security on your wallet. Even the famous Chuck Norris impersonator recommends it.


How does ROCA affect Windows secure boot? I've been doing some research on the Infineon vulnerability known as ROCA over the last few days. As I understand it, the vulnerability is present when a TPM running vulnerable firmware generates an RSA key. At that point, the public key can be used to derive the private key. My question, however, is how this affects secure boot in current versions of Windows. As far as I know, the TPM does not perform any key generation for secure boot and the secure boot keys are managed by Microsoft. Therefor, as far as the end user is concerned, ROCA isn't really relevant in the context of secure boot. Is this correct?

As far as I know, the vulnerable library is used by the Federal Information Processing Standard and by CC EAL5+, the same library is used in Windows 10 Secure Boot.

The RSA public key is made of two numbers N (2024 bits) and E (either 317, or commonly E = 2^16 + 1 = 65537), for the sake of performance some implementations use the small E, this implies that E=317 is vulnerable in all key sizes including 2,048-bit keys used in Secure Boot.

Check this advisory published by Microsoft (ADV170012) it lists all Microsoft's affected products.

This to say, YES in some cases ROCA could be relevant in the context of secure boot.


What do we do when passwords are not secure anymore? During an intense shower thought train. I began to think about a hypothetical world where passwords were no longer a safe way of protecting systems. Edit: W̶h̶e̶t̶h̶e̶r̶ ̶c̶o̶m̶p̶u̶t̶e̶r̶s̶ ̶b̶e̶c̶a̶m̶e̶ ̶t̶o̶o̶ ̶p̶o̶w̶e̶r̶f̶u̶l̶ ̶a̶n̶d̶ ̶c̶o̶u̶l̶d̶ ̶b̶r̶u̶t̶e̶ ̶f̶o̶r̶c̶e̶ ̶a̶n̶y̶t̶h̶i̶n̶g̶,̶ ̶o̶r̶ ̶s̶o̶m̶e̶ ̶m̶a̶g̶i̶c̶ ̶p̶r̶o̶g̶r̶a̶m̶ ̶w̶a̶s̶ ̶r̶e̶l̶e̶a̶s̶e̶d̶ ̶d̶o̶e̶s̶n̶'̶t̶ ̶m̶a̶t̶t̶e̶r̶ ̶h̶e̶r̶e̶.̶  (Let's not assume anything other than the 'fact' that conventional passwords cannot be used to secure systems)

If passwords where out of the picture, how would the general public go about securing their computers and online accounts?

We have no idea - yet.

Because passwords are insecure because of a combination of factors.

People choose bad (with only X bits of entropy) passwords.
Companies have bad password policy.
Passwords are stored in plaintext.
Password hashes are created with "bad" cryptographic hash functions.

All of these factors are theoretically "solvable".

We could tell people to use stronger passwords.
We could tell companies to have better password policies in place.
We could theoretically fine companies that store passwords in plaintext or when they create "easy" to brute force password hashes.

We (and a lot of other people) have been doing this for a long time and nothing or maybe little has changed. So your question is absolutely valid and has been asked before many times. The problem is, nobody has a good solution yet.

Why is that?
There are several fundamental problems: creation, storage, recreation.

Every factor that is used for authentication a) has to be created by something or someone, b) has to be stored on the client side (to transmit it to the server) and server side (to prove that it is correct) and c) it has to be possible to recreate a new one if it is lost.

All "new" proposals have at least a weakness in one of these categories. Take biometrics for instance:

creation: relatively easy, almost everybody has a fingerprint/veins/a face
storage (client): easy, on your body
storage (server): easy, either plaintext (several pictures are stored) or a hash is derived (both these solutions are suboptimal)
recreation if lost on the server side: not possible

There are other fundamental problems like usability, factor reuse, privacy etc. You can take every new proposal that is in the following list and is the topic of authentication research today and it will fail to solve at least one of the named problems.

What other solutions are discussed?
These: More biometrics (heart rate, voice, walking pattern), n-factor authentication, OTP everywhere, web of trust-like schemes, trust score system (scary!) and others.

In conclusion: We do not know what will come next, but there is a lot of research going on, because not only scientists but also companies are getting tired with all the problems that good old passwords have.


Pionee Red: Is this a Phishing attack? What should we do? I have just received an email from a close friend, which had "Pionee Red" as the subject, and the following body:

you've a new private message from your friend
Click To View The Full Message

As I hovered over the link, the following address appeared:

http://107.183.127.168/l/?gapaxobi=xayimasodo&batipikumemajojipo=&id=d2lsc29ubWFyYXZpbGhhQGdtYWlsLmNvbQ==&xuranoteyu=d2lsc29ubWFyYXZpbGhh

When I followed the link (from my VM), it took me to the screen below:

Where the email field was pre-filled with my actual email (not the one in the screenshot)

I went a little further and navigated to the IP contained in the original URL to see where that led, and it redirected many times before it finally took me to

http://www.kiss4you.com/

...where I was invited to Date Crazy in Happy Hours with more than 30 000 thousands of Beautiful Girls from Russia

Is that even a number? Crazy stuff. Anyway, what I wanted to ask is:

How badly might my friend's account be compromised?
Which security steps should we take?
Should we submit some sort of report anywhere about this?

This is a classic phishing attempt. Your friends email will most likely have been compromised the same way as you were. First of all:

Change your gmail password immediately
Change all passwords which may have been linked to your gmail account
(websites where you registered, etc...)

The website used is probably also compromised and is just used as webserver to harvest these emails.

For reports, you can get a police report if there is chance that sensitive personal information is breached, such as passport or ID copies, driver license, credit cards, etc... . Then it's best to make an official complain with the police. This will cover you should any fraud happen in the future that might get linked back to this.


How do certificates work in terms of encryption, hashing, and signing? I think I might understand this stuff, but I want to be sure I've got the details correct.  There is a lot of information out there on the high-level implementation of certificates, as well as the math-level implementation of encryption and such, but I haven't found very much on the low-level details.

I've written up my understanding, as best I can piece it together, but I'm sure I've goofed up details in some way or other.  Can you tell me what those errors are?  (And I don't mean what I've left out.  I do not want to discuss CRLs or X.509 formats, etc.  All that is implementation.  What I care about is a semi-idealized understanding of the process.)  Here's my write-up.

Thanks in advance.

Getting a certificate from a CA

A certificate authority (CA) is just an organization that has a public-private key pair and which others trust to verify identities.  If Alice (alice.com) wants to have a digital certificate signed by a CA, she generates a public-private key pair.  She creates a document containing some identifying information such as the FQDN and a person’s email address, etc., and encrypts it with her private key.  She packages this encrypted document with her public key.  This is the certificate signing request (CSR).

She sends the CSR to the CA and asks for them to verify her identity.  They use the public key to decrypt her document, proving to them that she holds both the public and private keys in that pair.  They may verify her identity in various ways, from automated and technical, to lengthy and legal, depending on what the purpose of the certificate is (authenticate an email address?  A web server?), whether it’s for an individual or a business, and what level of trust they want others to place in the certificate.

Once the CA has verified the identity of the applicant, then they will create a document containing her identifying information (may or may not be identical to what she submitted), together with her public key, and will “sign” that document by creating a hash of it and encrypting that hash with their private key.  The signature and some metadata (e.g., which CA generated it) are tacked onto the document, and the result is her certificate.

Verifying a certificate

Suppose Bob wants to verify Alice is who she claims to be.   She supplies her certificate to him, and he determines which CA generated the certificate.  Because he trusts the CA, he has their public key stored on his system.  He can use the CA’s public key to check the signature: He decrypts the hash with the CA’s public key, and calculates the hash himself as well.  If the values agree, then he knows that the document has not been tampered with, and that the CA vouches for Alice’s identity.

Using an intermediate CA

It is possible to have an intermediate CA.  In this case, the intermediate CA’s certificate issues the user’s certificate, and it has its own certificate signed by a higher-level CA.  For the user’s certificate to be trusted by others, the chain of signing must end up with a trusted root CA.

Your writeup checks out. One nit:

As dave_thompson_085 mentions, encrypting and signing are not the same operations. Although they may be implemented in the same manner in textbook RSA, does not mean they are the same. Indeed, X.509 supports ECDSA, where signatures are implemented entirely different.