Is it safe to store password in PHP session?

Don't store the password in the session variables. Instead, use a surrogate key.

For example:

Generate a random key. This is your surrogate key.
Use that key to encrypt whatever data you need.
Generate a storage key from your password, using an appropriate key-derivation function (e.g. PBKDF2 or bcrypt).
Encrypt the surrogate key with the storage key. If the two keys are of equal length, a bitwise xor of the two is an ideal form of encryption, since it's simple and cannot be broken without knowing one of the keys.
Store the encrypted surrogate key.

When the user logs in, you do the following:

Compute the storage key from the password.
Use the storage key to decrypt the encrypted surrogate key.
Store the decrypted surrogate key in your session variable.
Use the surrogate key to decrypt the data as necessary.
Destroy the decrypted surrogate key when the session ends.

If an attacker gets read access to session data stored in your /tmp directory, they might extract surrogate keys. However, they will not be able to get at the user's password. Whilst this doesn't protect the data you're encrypting on the server, it does prevent unauthorised access to the user's account, and stops the attacker from exploiting cases where the user has used the same password elsewhere.


Is this Data Encryption/Storage Method Secure?

You are using a 128-bit key (output of MD5, hence 128 bits) with a block cipher which expects a 256-bit key (Rijndael-256). If PHP was properly implemented, it would blow in your face at that point. However, the documentation states that the key is merely padded with zeros up to the required length. If you use a 128-bit key, you'd better use a cipher with expects a 128-bit key, i.e. Rijndael-128.

The "salt" is either useless, or poorly applied. Salts are meant to deal with weak keys, which can be realistically recovered by exhaustive search, i.e. when keys are passwords. If your key is a real, properly generated, fat and random key, then the salt is useless. On the other hand, if your key is a password, then you are in the real of password hashing, which will require more effort.

On the other hand, the IV should be random, instead of being the hash of the key. Appropriate use of the block cipher would be:

Have a unique 128-bit key, generated with a cryptographically strong PRNG (e.g. /dev/urandom on Linux systems).
When encrypting a new message, create a new random IV with a strong PRNG (i.e. openssl_random_pseudo_bytes(), which internally feeds on /dev/urandom or equivalent).
Forget about any "salt". Encrypt with your main key and the randomly generated IV. You then have to store the IV along with the encrypted message (for a SSN, you will end up with 32 bytes: 16 for the IV, and 16 for the encrypted block).

Then the following caveats apply:

This is encryption; it ensures confidentiality, not integrity. Someone who can modify parts of your database may play havoc with your SSN (if only by switching them around between users). Database integrity is a hard problem and the best known solutions are not good; they imply significant overhead.
Confidentiality is maintained only as long as the key is not revealed. But we envisioned an attacker who got an unusually privileged read access to the server contents, and the server, generally speaking, knows the key. If you keep the key in a file, separated from the database, then you may get some extra protection against basic SQL injection attacks, which work on the database contents only; but be aware that you have fixed only some vulnerabilities.


Encrypting session cookies on an Android device

1) Is this a valid finding?

Depends on the threat model. Is it allowed to use the application on a rooted device in the first place? Need it to be assumed that the rooted device is insecure so that a remote attacker can run its own malware as root on the device?

  2) If the application encrypts/decrypts the cookie on the device storage does this add more security or not because the application will have to store the key inside it?

It makes it harder but it does not fully solve the problem. The attacker might also change or hijack the application so that he gets access to the decrypted cookie.

  3) If the application will encrypt cookies does this mean it will be the same key for all devices obfuscated in the program code or it will be a combination of a key with random data generated on first run to have a unique key for every device and at the same time not have a standalone key stored with the data itself.

With a device specific secret it needs to be stored somewhere too which adds another attack vector (some devices have secure compartments which might help here). With a common secret more effort can be done to obfuscate it but also more time can be spend off the target device to analyze the application.

In general: the more control a user (or attacker) has over a device the less you can trust anything running on it. Thus you either need to make sure that the device can be trusted enough (like trying to detect root, make sure it has a current patch level, check for uncommon applications, trust only company managed devices ...) or to limit the impact of what can be done with a stolen cookie.


Are there other roots of trust on my computer aside from these 46 root certificates?

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.


The UK Terror Watchdog says this is very difficult in practise, is it?

Would it really be difficult to piece together the browsing history of
  an individual?

I think this is considered metadata. In my opinion, metadata can piece together what a user was doing:

  They know you rang a phone sex service at 2:24am and spoke for 18 minutes. But they don't know what you talked about.

  They know you called the suicide prevention hotline from the Golden Gate Bridge. But the topic of the call remains a secret.

  They know you spoke with an HIV testing service, you doctor, then your health insurance company in the same hour. But they don't know what was discussed.

Perhaps not totally on topic, but I hope you get the idea.


Does OpenPGP key expiration add to security?

tl;dr: the expiry date is no reasonable mechanism to protect the primary key, and you should have a revocation certificate at hand.

The slightly longer version is, that the effect of the expiration date differs between primary and subkeys, and also what you aim to prevent.

Subkeys

For subkeys, the effect is rather simple: after a given time frame, the subkey will expire. This expiry date can only be changed using the primary key. If an attacker gets hold of your subkey (and only this), it will automatically be inactivated after the expiry date.

The expiry date of a subkey is a great tool to announce you switch your subkeys on a regular base, and that it's time for others to update your key after a given time.

Primary Keys

For primary keys, the situation is different. If you have access to the private key, you can change the expiry date as you wish. This means, if an attacker gets access to your private key, he can extend the validity period arbitrarily. Worst case, you lose access to the private key at the same time, then even you cannot revoke the public key any more (you do have a printed or otherwise offline and safely stored revocation certificate, do you?). An expiry date might help in the case you just lose control over the key (while no attacker has control over it). The key will automatically expire after a given time, so there wouldn't be an unusable key with your name on it sitting forever on the key servers.

Recovering Weak Unrevoked Keys

Even worse, expiry dates might provide a false sense of security. The key on the key servers expired, so why bother to revoke it? There is a large number of well-connected RSA 512 bit keys on the key server network, and probably a comparabily large number of weak DSA keys (because of the Debian RNG problems). With faster processors and possibly new knowledge on algorithm weaknesses, an attacker might in future be able to crack the expired, but non-revoked key and use it!

Keeping a Revocation Certificate Safe Instead

If you've got a revocation certificate and are sure you never might lose access to both your private key and revocation certificate at the same time (consider fire, (physical) theft, official institutions searching your house), there is absolutely no use in setting an expiry date apart from possible confusion and more work extending it.


Anything better for cracking passwords than John if I have root?

If your ultimate goal is to actually get the password in plain text, then unless there's severe misconfiguration or undiscovered flaw in the password hashing method used, then no, there isn't a faster way to crack password than brute force.

Few points you could exploit: if you can get the shadow file out of the system, you could do brute force in more resourceful cloud systems like AWS or Compute Engine. Or if you can get the password salt and/or iteration count ahead ahead of time, you may be able to precompute a rainbow table.

However, most attack scenarios don't really need the plain text of the password. If you already have root, you can already do everything you ever needed to do, install ssh key for future login, alter sudoers to gain privilege on your non-root account, alter the kernel/OS to hide your changes, delete logs, etc.

If you really needed the plain text of the password, you can try altering sudo/su/sshd/bash/gpg binary to a trojaned version so that the next time the real admin typed in root password, the password will be sent to you. This may be helped by a little social engineering to convince the real admin to login to the system sooner rather than waiting indefinitely for that to happen who knows when.


I use a Bayesian scoring approach for a lot of my corporate sites. Some of the measures are a bit extreme, but I've found over time that most of the bot writers cut corners. That's not to say they haven't spent some time trying to figure out what's going on with my code.

I keep score per user, and a score per message. Also on some sites I'll keep score for an IP range by looking up the IP's registrant (via ARIN or something like that).

To begin with I set a timestamp. I pass it forward clear and hashed with a salt that I know part of myself (private key) and part of it is generated on the fly (temporary). This way it changes with every post.

On the next page I compare the timestamp with the hashes. If they're within a reasonable range of human interaction, then they're allowed to pass. If they're not, then they're obviously going to get negative points.

On registration I look for things like:

phone numbers that don't contain numbers
names that contain strings of numbers
email addresses for domains that aren't registered (or have no MX record in DNS)
I check their IP against their supplied country. (this one can be a bit tricky, so don't score it too high in the event they travel)
Websites that aren't registered - fake websites or websites like google, yahoo, or facebook (without a directory)
If they setup their profile so they have an offsite link to someplace I don't want or that is off topic they get a negative score
Additionally I block one-time use e-mail accounts and several of the free accounts where they don't have a clear policy about abuse.

In posts I and in their profiles:

I do a dictionary attack on posted content to check for variations of words. You have to be careful because a pattern in regex like !cialis! will match specialist.
If the posts are of a great length, I'll measure the amount of time the person has been on the site (logged in or not with a cookie) the length of the post and the average typing speed per industry. (Tech people type faster.)
I don't trust posters who are new to the site

Overall

I maintain a whitelist and a blacklist - The whitelist looks for exploited accounts as well.
I check referrers on handlers for forms. If they're not using the site (with the preceding page's hash) then their comment is flushed.
I check if their SESSION_ID is in the sessions table or not. If it's made up, then they're flushed.
I check user agents that are empty or things like cURL or Java.
I also check their contents with a ratio of vowels to consonants. If they don't fall within a normal range then they're flagged.
I check for words of enormous length without spaces. (This depends on the accepted languages)
And obviously things like semicolons followed by an exploit. (eg. ; UNION)
After all of that I do things like setup honeypots to non-visually-linked directories and scripts, so only someone looking at the code or mining for forms would find them. If someone from an address posts a link to one of the hidden forms they go into a database (replicated to my other sites) that contains known bad offenders.

Obviously blocking IPs might get a few false positives (for instance about 10 years ago I positively penetrated a competitor's site at one of the firms I was looking at with a <marquee> tag non-closed that made the content on their page walk off of the screen. They blocked all traffic from the firm's dynamic IP luckily we were using ADSL for that line and smart enough not to use our fixed ISDN line). We were using a secondary marketing approach to review their contents when I noticed an exploit on a hunch. (I told their programmer how to fix it.)

If you're trying to deal with a botnet that's a whole other animal, but most of the practices I've outlined above will work as well.

Check for proxies if you're only receiving malicious additions from proxies
Check for random IPs around the world within a reasonable amount of time (like someone has shared a login with a bot-net).
Try to use unique identifiers in cookies and urls to track people's movements throughout the site.

Normal posters will have a definite, noticeable pattern to their habits. Non-normal posters do as well. You just have to be diligent and spend a little time tracking their habits in databases.

For me, I always notice the patterns when I'm looking at a MySQL log of sessions, IPs, and traffic. I can usually catch the botnet setup session, then expect the worst. Most of the time it's script kiddies.

If you're worried about brute force, run something like iptables or apf. It will also stop some of the faster bots that try to post multiple pages at the same time, or the ones that post over and over to the same form without visiting any other pages.


Are there guidelines for application design of HIPAA compliant browser applications?

...falls under HIPAA's domain?

If you're dealing with PHI then the answer is probably yes.  Check out this page from the US Government Department of Health & Human Services Security Rule Guidance Material for some more information.

  are there guidelines I need to follow in the application design - the browser component? The back end I am confident is secure.

You should be thinking about a risk assessment (see above mentioned page, especially the link to NIST Special Publication 800-66).  It's good to be confident but you need to have the documentation to show that you have been thorough. Regarding application design, two good sources are the book Writing Secure Code and OWASP (check out the OWASP Top Ten as a starting point).

During your risk assessment you will be looking at threats (such as "looking over someone's shoulder") and you'll have to evaluate the likelihood of this happening and the risk that it represents.


Computer Science is just that a Science.  It would be very scientific to just hypothesize that you are secure without actually putting it to the test.

You can perform source code analysis and other whitebox testing methodologies to find all sorts of interesting and high impact vulnerabilities...  but what if no one could actually exploit these issues?  You can't get hacked with an unexploitable vulnerability,  yet systems are broken into on a regular basis.  (An insider could exploit an issue like this,  but that is a different question.)

Penetration testing to me is about using the Scientific Method to try and answer the simple question,  "In a real world scenario, what could a hacker do to harm my system or to my company?"  To answer this question you get a skilled hacker or team of hackers and purposefully debilitate them by not providing source code or access to the development team.   An ideal penetration test is a strictly blackbox testing scenario.  Just provide a company name,  or an IP address range or even physical address.  That is all the all the information an attacker should need. (The CISSP has a section of physical security for a reason.)

At the end of the penetration test you should receive a report with findings.  A good penetration test will always have findings.  There is no perfect system,  everyone can take steps to improve security.  From the results of penetration test you can identify weaknesses in your system and it can help you decide how to spend your resources to improve the security of your system as a whole.


This is by default disabled on those particular versions. For your exploit to work your database user would need access to the xp_configure command to enable the xp_cmdshell after which you can actually add your user.


What is the added value of dynamic payload in Ping/Heartbeat commands?

From a security point of view there is no reason for this.

The motivation is purely technical.

An arbitrary payload allows you to check not just if the system is able to respond in general, but also if the communication is free of any errors. An arbitrary size also allows to find out how the connection behaves when using larger messages. Standard ICMP pings with different length, for example, can be used to discover the fragmentation size of a network route and which router enforces it.


The first piece of code directly attempts to include the file conatined in the $doc variable.

<?php include $doc;?>

The second piece of code makes a file_exists() call and depending on the result of this call, attempts to include the file.

file_exists($finc)

file_exists is subject to PHP safe mode restrictions. These provide means to prevent the inclusion of specific files/directories that would otherwise be accessible. As stated in the PHP docs, PHP is not the appropriate place in the stack to enforce such restrictions, but this is a fallback mechanism should appropriate hardening and design/configuration practices not be present at the web server and/or OS level.

With the above in mind, you will be better able to perform LFI in the first code sample.


Simply put, there are various methods to masquerade a shellcode as a jpg file, but the file still needs to be executed. Whether you can do this depends on a variety of factors such as server and OS configuration. If you can somehow include the uploaded shell in the execution path (locally or remotely) and if specific security mechanisms are not in place, then yes, it's possible to execute the "jpg" file.

So even if you can upload a masqueraded jpg, it does not necessarily mean you can execute the embedded shellcode. What's more, there are methods to detect the validity of a jpg file (though even they can be bypassed with more advanced masquerading methods)

NOTE: The shellcode is merely the payload for the attack, and will only work if an exploitable vulnerability exists in the viewer and it is somehow possible to execute the jpg file.


What can I do about a malicious site with a similar domain name?

If you have definite proof that malware is being distributed from there, you might get the hoster to shutdown the website. Other than that, the person who has generic.com has every right to host anything that he wants on it.

Unless its a really specific domain name that is completely unique and you have reason to believe it was created to distribute malware to your users, you don't have a realistic chance of getting it shutdown.


What's a good fuzzing framework for fuzzing a local standalone application?

Updated answer: If you are using Windows, try the CERT Failure Observation Engine (FOE).  It is a fuzzing framework for Windows.  It has the ability to do file-based fuzzing, to click on dialog boxes, and other stuff.

Previous answer:
I suggest you start with zzuf.  It is the simplest, easiest to use command-line fuzzer for fuzzing standalone programs that read their input from files, stdin, or the command line.  It is extremely easy to use, and a good starting point.

You could also look at the CERT Basic Fuzzing Framework.

Then if you want to get more sophisticated you can look at other fuzzers (Spike, etc.), but that'll get you started.

If you want to fuzz programs that receive input via dialog boxes, sorry, I don't know what to recommend.


What allows for reinfection of the same PUP after quarantine and removal?

If the program is in Google Chrome's User App Data folder, it is probably being downloaded as a temporary internet file.  Every Time a user browses a website, the page is downloaded to that folder.  So either your wife has downloaded multiple versions of a malicious file, or she keeps going to the same page to download the PUP.  To eliminate the possibility there are just a lot of instances of the file, try deleting Google's entire folder in App Data and restarting the browser.

Other more advanced techniques could include a root kit, or a malicious version of chrome, but these are less likely.


Are image uploads also vulnerable to sql injection?

Actually they can be malicious. One of the challenges of the CTF of 29C3 was actually to upload an image and perform SQLi with it.

How did it work? Well images have metadata, after you uploaded the image, the metadata was extracted and put into the database. So the trick to get the flag was to include SQL in the metadata. (the input was not correctly sanitized).


How can I collect my clients' passwords?

If you're using a symmetric encryption, like AES, then the server can decrypt them since symmetric cipher uses the same key for encryption and decryption.

One improvement is to use asymmetric encryption like PGP. You can put the public key in the server, which allows the server to encrypt messages from clients, you'll then download the encrypted messages and decrypt them with the private key on your own machine.

Even better is if your clients would encrypt against your public key themselves, so the server never handles the plaintext even momentarily (it can even be any regular mail server), doing this correctly is much trickier than it looks but it's the most secure when done right.

For practicality though, I'd suggest using an online password manager that has password sharing feature, like Lastpass.


The Heartbleed bug was a SSL/TLS protocol implementation bug. OpenSSH does not use the SSL protocol in anyway (Although it does use some of the same cryptographic primitives).

So you don't need to worry about Heartbleed causing problems for OpenSSH.


I would guess the risk in this particular situation (Google services) is quite minimal, but you're always taking a chance when you enter the password of another account into a third party service. This is because it is unknown as to what they do with that data. They could do nothing, or they could data mine, sell, attempt to log in to other known accounts, and/or otherwise run analysis on passwords entered there.

There are a few things to consider, for example if the username of the two accounts in question are not the same it adds a layer of obfuscation to the mix. What username would they use to log in to your account on another service with out more information about you and your online presence? How would they find the right service to use the correct combination of username and password?

When to be worried? I would worry if I were using the same username on multiple online services where I didn't particularly trust their origins (think sites like hackforums.net).  If you're doing something like this it could be easy for a black hat owner of the service to do some recon on your username by way of Google "hacking" or namechk.com and trying your passwords on your accounts.


What specific assurances exist about StartPage privacy?

Startpage.com has a contract with Google that allows us to use their official "Syndicated Web Search" feed, so we have to pay them to get those results. Sometimes we get slightly different results, but in general, they are the same high quality.

We serve those results to you in privacy. Google never sees you, and we never log any user personal information. Even Edward Snowden has recommended Startpage.com for its no-logging privacy.

You can be sure we never share your personal details with any third party, including Google. Your privacy is absolutely secured. You can read more about this in our privacy policy.

Can users trust Startpage.com do do what it says and maintain its privacy promises? We have an article on this here.

If you would like more information, please feel free to email our tech team: Support@Startpage.com.


Plausible scenario for a PHP session fixation attack with default settings?

The only other way I can think of is a script on the site but if we already have a shell, why bother with sessions?

You wouldn't. If you have code exec, there are worse things you could do.

But an attacker isn't the only one who can write code. I have seen code similar to this a couple of times in PHP applications:

  session_id([userinput]);

This then introduces a session fixation vulnerability. If session_regenerate_id were used on login, it would at least reduce the impact.

  Javascript will require both session.cookie_httponly to be Off and also a working XSS.

If you have XSS, there are worse things that can happen than session fixation.

But as with the PHP code example above, one could imagine JS code from the application reading a user-supplied value and setting it as cookie. You might also have a limited XSS issue which eg only allows injection in a meta tag, via which you could eg set cookies.


Can enforcing a website to serve SSL requests only prevent SSLstrip from working?

Will that be sufficient enough to prevent the attacker from using SSLstrip to downgrade HTTPS to HTTP?

No.

  I would assume the webserver will fail to serve non HTTPS traffic, correct?

No.

The MitM will speak https with your server and http with the client.

The only real defense against sslstrip is HSTS.

According to https://www.tbs-certificates.co.uk/FAQ/en/hsts-iis.html you can set-up HSTS with IIS with the "Add Custom HTTP Response Header" dialog.

Note: HSTS is only active after a first successful https visits. To protect the first visit, you can use the preload mechanism: https://hstspreload.org/ but be careful, it's can't be disabled after!


What makes VoIP more vulnerable than a "normal" phone line?

First off, I like the amount of passion you have for the subject!

Now for the answer:
VoIP is a digital way of sending voice communications using IP.
An example for this would be sending voice over the internet between two VoIP nodes.

Because VoIP uses the internet to communicate, the access to the nodes and to the servers handling the requests are at risk to the whole world. This means that if I scanned the internet and found a VoIP node and I found a vulnerability then I can use the node's OS for any malicious purposes (Example: using it as a bot in a DDoS attack, sniffing the traffic and there for listening to the calls and etc...).

On a traditional phone line the communication is done via a private closed off network that is wired to your house from a control box that is probably somewhere in your neighborhood (And that box is connected to another and so on until the main control system).
In order to hack that you would have to connect to this wired network. This requires physical access which already makes it harder to hack then a VoIP network.

There are many more small reasons and each have there own good and bad sides but in general the reason VoIP is more vulnerable is because it uses the internet or any other network to communicate which makes it vulnerable to all standard attacks. Either way, they are both pretty hackable each in their own way.

Note: Some service providers have already mixed together there control systems for the phone lines with the internet making it also vulnerable.


Does FTPs (FTP over SSL using explicit TLS) support encryption of data channel?

You are correct in that SSL/TLS does provide encryption of the data.  However, one thing to keep in mind with FTPS is that there are actually two TCP connections involved: the control connection (e.g. to port 21) over which FTP commands are sent and responses received, and the data connection, over which requested data such as directory listings and file uploads/downloads are transferred.

The PROT FTP command is for configuring the protection for those data transfers; see RFC 4217, Section 9 for the specification/details.  The control connection will have its SSL/TLS session, and thus be encrypted (and protecting your USER and PASS values).  But should the data connection also use SSL/TLS?  Some use cases may say yes, some may say no.  Most sites wishing to use the full benefits of SSL/TLS for data private and confidentiality will want to use PROT P for encrypting the data connection, in addition to the protection on the control connection.  Sites that don't want this may allow FTPS clients to send PROT C, to request that data transfers not be encrypted.  (And some FTPS servers also allow the CCC command, which can be used to remove the SSL/TLS encryption from the control connection.)

Hope this helps!


Are deleted files more or less likely to be overwritten than blank space?

Yes, I take them into account.

On HDDs it's more like o be overwritten compared to being stored into free space, because the tendency is to put the data into the faster portion of the drive which is at the beginning of it.

For SSDs, in theory, the data should be allocated to the less used sectors, which means there's a higher chance data will land into the free space compared to reusable one.


As the documentation for dumpcap shows you can simply write to stdout, i.e. dumpcap -w -. Then you can put whatever you want after this, i.e. something like

 dumpcap -w - | your-own-analysis    # analyze it directly
 dumpcap -w - | nc ip port           # send for analysis to some remote system


Is there any way to authenticate a HTTP client only once?

No, because HTTP is stateless.

  data that comes from the client is encrypted...using the master key

Both the content in the browser, and the stuff on the server is the application. Where is encryption happening?

  The data that is sent by the application to the client is decrypted in the back end and then sent over an HTTP protocol

OK, so when you say application you really mean the server-side?

It would appear there is never any requirement to store the "master-key" on the client.

  sign in form in the client and it only requires a master key

You use the encryption key as an authentication token as well? Really? You expect users to type in something like

c48bb691eb5e2f609192ed5a981c6f8745896aa968604c1cdf70cb57ebc0d421

every time they log in? I'll bet you're either allowing them to pick really simple passwords/keys or they are storing them somewhere.

You could simply store the master key server-side in a HTTP session variable. But if this really is a "master" key, then the clients/users should have no visibility of it. You need to separate the authentication from the encryption.

There are various things you could do with local storage, a second server, encrypting the master key with the user's password to protect it, but without knowing a lot more about the platform it is impossible to advise (and becomes too complex for a discussion here).


Using Diffie-Hellman exchange on low power IoT devices

It depends on 2 factors: what resources are available on the IoT device (processor speed, memory, power), and how long you can wait for the data to arrive. If one of those factors are not an issue (say, you can wait 1h to receive 1024 bytes), it can be done on any device.

Generally, current technology is more than enough to run basic cryptography, the bandwidth and latency being the main issues. The low-power microcontroller Maxim MAX32621 (12mW on active mode, 2.6 µW on standby) can do AES-128, AES-192, AES-256, DSA/RSA to 2048 and TRNG native. Someone even implemented AES-CMAC on an Attiny85 (8k flash, 512B RAM, 8/16MHz, up to 20MHz).  EDHOC intends to solve the latency by, among other things, reducing the amount of round-trips needed to establish the connection.

If you don't care about implementing the full TLS stack, but only on encrypting data, you can implement your own protocol. Save the server public key on the device, generate a symmetric key, encrypt it with the server public key, encrypt the data with the secret key, concatenate both the encrypted data and encrypted secret key, and send to the server all at once. No round-trip, no TLS session establishing. If you use UDP, you can send all the data in one single packet, without even needing to establish a connection.


How to explain Heartbleed without technical terms?

How about this one from XKCD?

The most "non-technical" explanation I found.


Intermediate CA authenticity in an embedded device

Being a CA means that there is a great deal of trust placed in them.  The global CAs present in your browser and OS all follow the CA/Browser Forum rules regarding who they will issue certificates to, how they validate clients, and what kinds of permissions they'll allow on certificates.  Very specifically, a global CA will not issue anyone a certificate with the KeyUsage field permitting either keyCertSign or cRLSign.  This means you cannot create your own intermediate CA signed by Verisign, because that would allow you to forge certificates for anyone on the planet. Verisign would lose their global CA status quickly if they issued signing certificates to their clients.
To use client certificates the way you're describing, your organization has to have your own private PKI and distribute your own organization's trusted CA root certificate to all participants.  Your PKI is then free do do whatever you need, such as issue an intermediate CA a certificate that can sign client certificate requests.  But just like trusting the global CAs, you must place a lot of trust in your private PKI, espeically to not sign inappropriate requests.
Larger organizations that run their own private PKI will often use a certificate request management system that serves as a protective front end to their signing CAs.  This system's job is to authenticate that certificate signing requests (CSRs) come only from authorized consumers; it ensures that incoming CSRs don't request inappropriate permissions; that CSRs all follow corporate policies and standards for every field; and they'll keep an inventory of all issued certificates (which can come in handy if you need to know when certificates in your organization are about to expire.)
Your PKI team would rely on such a system to not issue Subordinate CA signing permissions to anyone but the PKI team.  This would prevent a client from generating a rogue intermediate CA.  And that's what prevents the scenario you describe.


Which are the most important RFCs when learning security?

Learning Basic Networking is very important.These are protocols specific RFC's , to gaing in-depth knowledge about a particular protocol.
You can approach by :
for example IP RFC 791
First study and learn IP from IP RFC,or various resoures.
After Having the knowledge of IP , you can find out what are the different security problems related to IP.
For example in its design , its header , various ways an attacker can manipulate and use IP protocol,spoofing,replay packets etc.
Than finding the safety measures required.
This may lead you to ipsec,firewall(iptables).
Then finding how ipsec saves you.
For that go for IPsec RFC and find out how it solves various security problems you have encountered earlier.
If ipsec is not the complete solution find out more.
You can keep on researching on DNS,HTTP etc
Hope it helps !


What can be accomplished with a site that is vulnerable to both XSS and SQLi

There are two ways that XSS and SQLi could interact. The comment you quoted is from this question and is clearly regarding the first point.

SQLi via XSS

If you know that an application is vulnerable to SQL injection, but you do not have the permissions necessary to access the vulnerable component, you may be able to leverage an existing XSS vulnerability and thus get a more privileged user to perform the SQL injection for you.

As you point out, finding vulnerabilities in components that you do not have access to may not be that easy. There are still at least two cases where this can easily happen though:

Open source software
Temporary access to the source code (maybe via an external auditor, via Email leaks, via a disgruntled ex employee, via vulnerabilities in your source control, ...)

For very simple injections, an attacker may also just guess an attack (maybe an attacker knows that your application doesn't defend against SQLi at all, but all injections in components they have access to are using a database user with restricted permissions; here they might actually be able to guess script- and parameter names of other components and exploit those via XSS).

Theoretically, you could also imagine a setup where more privileged users are always using a database connection with a more privileged database user, so even an injection in public components may be more powerful if exploited via a more privileged user through XSS.

The last examples are a bit contrived, but certainly possible. There are likely other examples as well.

XSS via SQLi

In this case, you have an SQL injection, but cannot actually achieve anything interesting with it. The injection may take place with a very restricted database user, who for example can only read out already publicly available data (but cannot read out other data, write data, write or read system files, execute commands, etc; there are also no vulnerabilities in the dbms you can exploit).

In this case, you might be able to perform a reflected or stored XSS attack via SQLi.


Avoiding repeaters in radio-communication

The classical situation for radio-frequency repeaters threats concerns all radio-based identification/authentication systems (RFID cards, etc.), the goal being to establish a tunnel between the actual card located at a distant place and the authentication mechanism (a door lock for instance).

In such case, the goal is not to exactly to use timing (such authentication token just have no clock at all!), but to establish a challenge between the two involved parties and evaluate the latency by measuring the time needed for this challenge. If both parties are in a short range as expected, the latency should never go over some threshold, while if they are out-of-range with some relay retransmitting the signal, the latency may go over this range.

However, this solution is valid only if there is some protocolary communication between the involved parties, and if the considered threat involves a minimum distance between them to induce detectable latency.

The other solution becomes completely implementation dependant, and consists in trying to detect anomalies:

Assume that each satellite, sensors or whatever bears a unique ID. The fact that the unexpected signal from F is received while A, B and C are also received may be detected and considered as an abnormal situation. This would require some mapping, some memory of the previous signal encountered while in learning mode, or some other special disposition which allow to deduce this anomaly using some algorithm if the ID can be disposed in a way matching some law (ID would merely be actual coordinates for instance).
Following the same principle, if the robot is constantly listening radio information, signal strength may also be used to detect any brutal change in the signal strength of some sensor while the signal of the other sensors remains unchanged: this would clearly indicate an issue.
Or something else, in your description the sensors communicate with the robot. Why not also include sensor-to-sensors communication in your scheme? The presence of repeater in such a network would inevitably create new connection nodes in your network, thus raising an alert.

These are a few ideas which came to my mind. However, as stated in the different comments, there does not seem to be any well-known standard at this level, so unlike what is recommended in usual cryptography you will most probably have to "roll your own" here in a way or another.


Functional Google 2FA code (via SMS) received from a random (but in use) mobile phone number

The SenderId of an SMS can be easily spoofed by anybody betweeen Google and your phone. Note that Google does not directly send you an SMS but uses service providers that have network connections (maybe indirectly) to your phone. And since the Telcos between Google and your phone want to filter out non-person-to-person traffic (because of $), it makes sense for someone on the route to make the SMS look like person-to-person (p2p) traffic by choosing a (random) SenderId that comes from a p2p number. And if that number is already in use, even better. :-)

I work at an SMS aggregator who develops 2FA, delivers SMS for 2FA, uses SMS routes, and has heard of SenderId spoofing.


Encryption and HMAC with the same password

Here are some weaknesses (the first one is the most serious):

If you do not include the encryption IV in the input to HMAC, then attackers could modify the IV and induce a corresponding change in the message without being detected. Similarly, the attacker could modify SALT1 or ITERATIONS1; the HMAC would still match, but you would get junk upon decryption. For encrypt-then-MAC, you MUST compute the MAC over everything that contributes to the decryption. In your description, the HMAC input should be an encoding of a structure containing the encrypted data itself, but also the IV, SALT1, ITERATIONS1, and any symbolic identifier for the used algorithms (in case you want to make some provisions for algorithm agility).
PBKDF2 is a password hashing function. It is made slow with a lot of iterations. Since slowness impacts attacker and defender alike, you cannot set the iteration count arbitrarily high. In your description, the defender must use two PBKDF2 invocations in normal usage, thus paying for both; whereas the attacker can run his dictionary attack on either. So the cost for the defender is ITERATIONS1+ITERATIONS2, whereas the cost for the attacker is only the smaller of the two. This is an advantage to the attacker.
PBKDF2 is not the best in class; it can be executed very efficiently on a GPU. Bcrypt would be better (see this answer).
You are relying on PBKDF2 behaving like a sort of "random oracle" with regards to the salt value. It so happens that in the case of PBKDF2, this is plausible (PBKDF2 is a chain of nested HMAC, starting with the salt). However, this is not a much studied property and you cannot count on it for just any password-based key derivation scheme. It would be safer to use cryptographic primitives the way they were intended to, because security comes from scrutiny, and exotic usage of algorithm has not, by definition, been extensively reviewed by cryptographers.

A better scheme would run one password hashing function (say, bcrypt), with one salt and one iteration count; and it would then expand the result with a Key Derivation Function (a fast one, e.g. HKDF) into a sequence of bytes that you would split into an encryption key, and a MAC key. This is, incidentally, how things are done in SSL. If you are in a hurry and don't want to implement an extra KDF, you can use in many cases a simple hash: compute SHA-256 on the bcrypt output, yielding 256 bits; the first 128 bits are for the encryption, the other half for the MAC.

In all generality, it is preferable to use authenticated encryption. CCM is an early attempt at an AE mode; better choices are EAX and GCM. The latter is fast becoming a standard for such things, and has been blessed by NIST. It is supports in SSL/TLS (since TLS-1.2) and is available in some widespread libraries (e.g. OpenSSL).


Can I send a Medical Record Number (MRN) via email internally?

DISCLAIMER: I am not a legal expert and I strongly believe you should consult one. This answer is based on my reading of the rules. Others may read them differently.

First, note that Microsoft claims that Office 365 can be made HIPAA compliant if you have a "Business Associate Agreement" (BAA) with them. See the Microsoft Trust Center - HIPAA for details.

The HIPAA Privacy Rule explicitly lists an MRN as Protected (PHI), meaning that the Security Rule disallows sending it over an insecure system. By default, Office 365 would be considered insecure for this purpose.

However, if you have set up a BAA with Microsoft, which Microsoft's marketing literature says will make your Microsoft Office 365 be HIPAA Security Rule compliant, then sending PHI over this properly secured system would not be a problem.

NOTE: You still need to make sure that any computers or mobile devices which access the email server are set up for HIPAA compliance, but that is outside the scope of this question.


Yes it would be possible to use the amavisd-new and Google Safe Browsing Lookup API specifications to write an e-mail scanning plugin that would "scan" all URLs in e-mails. The amavisd-new spec is written in Perl, so it would probably be easiest to write the plugin in Perl as well, but not necessary as according to their documentation.

As Andrew mentions, this type of scanning would likely be most useful if integrated in to a larger framework, like SpamAssassin, where it can be a contributing factor to the classification of incoming (or outgoing, in high security environments) e-mail.


Could someone on the outside somehow see the request and fake a response?

Someone who is both physically and logically outside the network cannot fiddle with the intranet. But while  keeping an attacker physically outside is comparatively easy to guarantee, keeping the attacker logically out of the internal network is much harder.

  And for the sake of the question, you can assume that everyone on the inside is trustable.

I don't think that you actually mean "everyone on the inside" but more "everyone who is legally allowed to be on the inside". While you hope that these are the same users this is not necessarily the case.

But have a look at the users who should be legally in the network: even fully trustable users are not infallible and might be tricked into letting the attacker accidentally and unknowingly into the network. Typical current ways are phishing attacks where the user gets for example a mail from a seemingly trusted person with an office document (containing macros) or some executable which looks like an office document or PDF. By "opening" this document the attacker gets access to the internal network and the user might not even have noticed anything unusual.  Also, internal systems might be vulnerable in a way that they might be infected if the user visits an external site from inside the same network. Or how about an attacker taking over the networked printer and from there the network just by tricking someone inside to print some document.

As a result your network might now contain users who should not be legally there and who you can not trust. You cannot really be sure who really has access to your local network unless it is fully separated (physically and logically, i.e. no data exchange by USB sticks or similar) from potentially dangerous networks.

  How big is the man in the middle threat from outside the network when communicating on an intranet?

How big the risk really is depends on the network. The less you know how your network works and what should happen in the network, the more likely some attacker knows more about it and makes use of this knowledge. On the other hand if you spend lots of money to protect your network it is usually since it is really valuable - in which case an attacker will probably also invest more resources to get into it.


What encryption protocol is used by paragonie/Halite library by default?

What encryption protocol is used by Halite library by default?

This is explained in the Halite documentation.

Halite uses XSalsa20 (the extended-nonce construction of the Salsa20 stream cipher) with a keyed BLAKE2b hash for the authenticator, Encrypt-then-MAC.

If you prefer to look at source code, see here.


Does use of WEP only open the network to attacks in proximity of the router?

Always remember the OSI model. WiFi signal and encryption exist on the lower levels of the model, which by necessity means that the attacks that it mitigates, and the possible attacks against it, also exist on those layers.

The realities of the way WiFi is implemented in those layers mean that it is all about the radio signals, which means that the topic is confined to what can happen to the radio signals.

So, if you were wondering if someone over the Internet (layers 3-4 and above) can attack WEP/WPS, then no. The attacks are within range of the radio signals of the device.


You can do this yourself. Just edit the /etc/resolv.conf file and add the IPv4 and IPv6 DNS servers. Most modern operating systems cache the requests to limit unnecessary requests, you might want to flush this first. Restarting the network interface will do.


By default, Burp uses 50% of your system memory. This default is suitable for most uses and you should not normally need to override it. If you do want to override it (perhaps because you have lots of system memory and less than 50% is sufficient) then you can edit the vmoptions file in the Burp directory and override the memory limit.


It basically boils down to trust. Most software packages are digitally signed. If they are signed by a trusted certificate you can be more sure of their identity. It's however not fool proof.

There is no real other way of knowing, if you want to be sure you will need to review every single bit of code which is not possible with Windows as it is a closed source operating system.


Encryption for a system supporting only basic cryptographic functions

Your 'strong' key is just a hmac with static content - you would be better off implementing HKDF for your key strengthening portion if possible. It would also be worth ensuring your random IV is random enough - an error there will stuff things up a lot.


Will dm-verity protect against firmware malware on storage devices likes HDD or SSD?

Absolutely. dm-verity operates at a higher level than firmware, so as long as the malware does not show its true colors, dm-verity will do nothing.
Such a malware could only operate (apart from destroying the data on its storage) by supplying different data than it is stored. For example, upon activation, malicious code would be "read" from the disk where intact code is actually stored. That operation would be caught by dm-verity:
From the docs:

dm-verity protection lives in the kernel. So if rooting software
compromises the system before the kernel comes up, it will retain that
access. To mitigate this risk, most manufacturers verify the kernel
using a key burned into the device. That key is not changeable once
the device leaves the factory.

The firmware hack does compromise the system "before the kernel comes up", but then it would hit against the read-only key check. So the hack would need to also disable the verity code (which may or may not be possible depending on where exactly this code resides).
On the other hand, how exactly is the key recovered? The kernel has to ask the device for the key, and while an external program cannot change the key, the hacked firmware can ignore this fact and report a different, changeable (and changed!) key.


Spoofing HTTP Request headers within javascript?

Unlikely as this would be a serious security issue. However, as @elsadek suggests, it might be possible from a browser addin which has more access. Certainly not possible from in-page JavaScript.

However, in terms of blocking tracking pixels. The issue is, how do you know whether an image will be a tracking pixel image BEFORE you access it? Once your browser has issued the request for it, the server already has your details.


DSA is a signature algorithm; its keys are not usable for asymmetric encryption. In the OpenPGP format, algorithms for encryption are RSA and El-Gamal.

Normally, when you create your keypair, you are actually producing several key pairs: a "master" key, and some "sub-keys" for signing and for encrypting. The master key signs the sub-keys. When you say that you use "DSA 3072", you really mean that your master key uses DSA 3072. Similarly for your friend.


Sending data from Android client to database

In general, this can't be done.  If the user has access to the app, they can reverse-engineer it and undetectably emulate everything it does.

What you can do is put obstacles in their path.  Simply transmitting a salted hash alongside the data will stop 99% of would-be attackers; if you're willing to go to greater effort, using public-key cryptography to encrypt and sign the message being transmitted will stop almost everyone.

This won't stop or even significantly slow a professional attacker, but if your primary threat model is "college student majoring in art history" or "casual Facebook user", it's more than adequate.


What elliptic curves are supported by browsers?

When software (browsers, Web servers...) supports elliptic curves at all, you can more or less expect support for the two curves given in NSA suite B, i.e. the P-256 and P-384 curves which are specified in FIPS 186-3. These are the same curves as the "secp256r1" and "secp384r1" which you list. The 15 standard NIST curves (from FIPS 186-3) are actually a subset of the curves specified by Certicom in SEC 2.

Some software implementations go further and support other curves. For instance, OpenSSL supports all 15 NIST curves (code was contributed by Sun and is believed not to infringe on any patent -- which explains why OpenSSL does not implement acceleration of Koblitz curves through the Frobenius endomorphism). But if you want to maximize interoperability with existing browsers and servers, stick to P-256 and P-384 (I think these are the only two which will work with Internet Explorer, for instance).


How do services prevent malicious behavior when executing user provided code?

I will give you some examples of how to detect by the platform your examples of malicious behaviour:

For cryptocurrency, probably by limiting the time of the execution you can block this types of attack, as far as I know for example bitbucket limits the time of the builds and deploy, so if you want more time you need to pay. Basically if you want more CPU you need to pay.
Sending spam, If your software makes too may connections to the Internet and your software is uploading traffic you can limit this. Also NIDS can detect this.
For the DDos attach is a similar approach as the previous one. Also the docker could be executed on a non secure environment with NDIS, firewalls and other security systems basically and will detect the attack.
And the other case is easily detected by the other two techniques mention or by the destination service that probably will contact with the platform and informing about the issue.

Be aware, that in general github, bitbucket and so on have security systems in place and if you are using free accounts you are on a different schema than a company that use that services. On the other hand, if the platform have the suspicious or the evidence that you are making some bad activity im sure they will block the access to the account and send you a lovely email :)


Does the main OS run "virtualised" under the ring -1 hypervisor?

Hardware virtualization
If an operating system is not a host virtualizing a guest, it is not running as "ring -1". If a hypervisor is not active, ring -1 effectively does not exist and does not matter. As such, unless you are purposefully running a virtual machine, you don't have to even think about hypervisors. The short answer is that ring -1 is not a real protection ring. It is a term made up to illustrate the relative privilege difference between a virtualized guest and its host.
Current Privilege Level
In CPU parlance, ring 0 is called CPL0 (Current Privilege Level 0) whereas ring 3 is CPL3. The purpose of this is simply to allow various instructions to check the amount of privilege before executing. A task stores its current privilege in the TSS, and instructions are able to have checks to ensure that only a certain level is allowed to continue. For example, the RDTSC instruction is defined as:
if(CR4.TSD == 0 || CPL == 0 || CR0.PE == 0) EDX:EAX = TimeStampCounter;
else Exception(GP(0));

This includes a check to see if the current privilege level is 0. If it is, then it will save the value of the timestamp counter to the EDX and EAX registers, otherwise it may result in a general protection fault due to insufficient privilege.
Privileged instructions and VM exits
Hypervisor context is not a real protection ring, and CPL < 0 will never evaluate true. When a privileged instruction is to be executed in a guest, it is automatically trapped and the guest exits in a process called vmexit, and the hypervisor is allowed to determine whether or not the instruction should be allowed, and can safely emulate it if it so wishes. After it has made its decision, it gives control back to the guest using vmenter, and the guest continues along like nothing happened until it runs into another privileged instruction that forces it to give control back to the hypervisor.
Certain non-privileged instructions can also be conditionally trapped in a hypervisor, for example CPUID, which gives information about the processor. While this is not privileged (normally, at least), it is quite useful for hypervisors to trap it so they can modify the values it returns. A guest running under KVM or Xen calling this instruction with EAX set to 0 will return the vendor ID string KVMKVMKVM or XenVMMXenVMM, respectively, in three other registers. If the instruction were not trapped, the bare metal result would be something along the lines of GenuineIntel or AuthenticAMD. It is not necessary to trap this instruction for security reasons like it is for instructions that poke hardware ports, but it is quite useful in the context of managing the guest's view of what it is running on. It is possible to disable trapping for some of these instructions. Section 2.7 of the technical documentation for Intel VT-x explains the different events that can be made to conditionally trigger a vmexit. Instructions that are sensitive are trapped unconditionally.
For securely managing a guest, rather than simply checking privilege level, the system checks if the instruction is running in virtualization context. The effect is the same (a more privileged context can overrule the decision of a less privileged one), but it is implemented using hardware virtualization technology rather than x86 protection rings in the TSS. This is why the hypervisor is said to be more privileged than ring 0, because even in ring 0, a guest can have its decision overruled by the hypervisor. Since lower rings mean more privilege, and ring 0 is the most privileged level, naturally this has lead to a context with even more privilege being nicknamed ring -1. The only purpose in that naming is to help people remember that ring 0 is not necessarily the most privileged context a task can run as.
Ring -2 and -3
There is also ring -2, for System Management Mode, or SMM (a special, highly privileged context which the CPU enters when a type of interrupt called an SMI occurs), and ring -3, for coprocessors that have a high level of control over the system (such as the Intel ME or AMD PSP). None of these are actually implemented as protection rings, and a ring -3 task isn't even running on the main CPU.


3rd party requires my server's public key for a secure connection?

This is TLS Mutual Authentication.

It is a proven and well-documented part of TLS and happens during handshake.

Nothing unusual is happening and the handshake is specified to fail if you do not supply the client certificate.

MitM is definitely still a concern, but that is mitigated for you as a client by CA trust and signing (or certificate pinning) on your side and by similar CA trust (or client certificate pinning) on the server side.  Someone supplying a forged certificate from a MitM position will need to be CA signed or to social engineer one side or the other into pinning their malicious certs.

IMPORTANT: you MUST provide the client cert (if not CA signed) in a secure manner to the server operator.  In-band key exchange is certainly not up to this task.  One option is to publish the cert on a secured HTTPS endpoint for a domain you own from which the server operator can download the cert with confidence that it is from you and hasn't been tampered with in transit.  This has its flaws (incompetent CAs, server compromise, etc.), but it should be sufficient for most cases.

There's a good description of the process here:
http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication


Disable insecure/dangerous PHP functions

There are a number of things that must be understood here:

List of dangerous PHP functions is located here: http://php.net/manual . Seriously, almost any PHP function can be dangerous given the right context. strlen and like are probably safe, but any function that talks to outside world can brings surprises if the rest of the code is not safe.
If you want to secure the site, the security should be throughout the code, just disabling some function here and there is not going to work, only going to blind you and lead to sloppy coding.
There are capabilities in PHP that can assist you in writing more secure code, however they won't make secure code from insecure one. Look for open_basedir and allow_url_fopen as an example.
You can use disable_functions to prohibit some actions that you consider dangerous, however only certain classes of actions can be inhibited this way. For example, you can disable exec,shell_exec,popen,passthru,proc_open,system,pcntl_exec and this probably will prevent running external programs from your code - but most of the things done by these programs can be done by PHP means too. And trying to avoid things like "writing a file" probably won't work - you should do it via OS permissions, not via PHP. So, define what exactly do you want to prohibit first and then see if it's possible - while keeping in mind it may be impossible.
Read security chapter in the PHP manual. Read some PHP security books. Security is not done by just setting security=On in php.ini, unfortunately.


Key Generation on FIPS device or using SW with FIPS generator

From a technical standpoint, not really. If you want to adhere to FIPS 140-2 Level 3 requirements, absolutely not.

FIPS 140-2 Level 3 has very specific requirements, including resistance to information leakage when an attacker has some restricted level of physical access to the device. This means that a certified implementation must ensure that the implementation of key generation and the cipher itself is resistant to side-channel attacks such as power analysis and electromagnetic emissions. Level 3 devices undergo rigorous EMC testing above and beyond that of normal electronic products. By taking key material from a FIPS 140-2 Level 3 device and transforming it needlessly on a non-compliant device (e.g. a general purpose computer) you nullify the EMC protection that the device offers, and potentially offer up other side-channels in the process.


Internet security demonstration of TLS for laypeople?

Do what amounts to be a "magic trick". Set up:

a web server with a basic login page and a file upload feature
a client machine with a web browser for a student to use
a sniffing machine

Get the user to log in with any username and a fake password, make a Word file (or similar) with a message and upload it.

Use the sniffing machine to discover the password and save the Word file and read the message. All of this is scriptable on the sniffing machine.

Then you explain the magic trick, show them the password string in the capture, then turn on TLS and show them the encrypted text.


Drawbacks of storing an authentication token on the client side?

Since you'll be making calls to the API server via Ajax (meaning the same page - and the same JavaScript context - will be constant) I'd suggest creating a short lived token in the main server, having the browser request it once, then using it to authenticate with the API server until the page is closed (or the token expires, whichever happens first). Next time the user visits the page, generate a new token.

This way the calls to the main server will be infrequent (and you can't avoid them anyway, since every time the user logs out or clears the cookies he'll have to authenticate with the main site again), and you avoid the hassle of having to secure yet another piece of data.

As for Local Storage attack vectors, I believe in theory they're roughly the same as the ones related to cookies - XSS, physical access to the machine, etc - since it's subject to the Same Origin Policy (at least those created by a SSL protected page are), but contrary to cookies it does not support a restricted visibility by path (i.e. all pages in the domain can access data from any other page). In practice, however, there might be inconsistencies in the way it's implemented, as well as other security holes, so I wouldn't trust it unless I was highly confident it is secure (something I can not really assert with my current knowledge). According to this OWASP guide storing sensitive data in Local Storage is discouraged. SessionStorage is not bulletproof either.


How do iOS 11 apps identify me despite app reinstalls?

Since iOS 11 it seems like the "keychain" (per-app secure storage for API keys, etc) is no longer deleted once an app is removed, so apps can persist their credentials (and of course ad tracking nonsense) in there and get them back when they're reinstalled.

The only option at the moment is to completely reinstall the device if you want to clear this, as the keychain is per-app so you can't even use another app to clear it, and there is no built-in way to do this. I imagine it would be possible with a jailbreak but that brings its own risks.

I've raised a bug with Apple about this and I suggest you do the same to push them into reverting to the previous behaviour of clearing the keychain of deleted apps.


EMV Security? How is it possible that it's secure?

EMV is a communication protocol, and by implication it specifies what data must be stored on the credit/debt card. It doesn't specify what technical measures protect the card as a physical device. EMV is irrelevant to your question.

To understand why a chip isn't so easy to duplicate, read about the physical security of smart cards. There isn't much public literature on the subject, both because it's somewhat of a specialty topic and because some of the techniques are unpublished.

There is a good treatment of smart card security in Security Engineering by Ross Anderson, §14.16.2 in the chapter on physical tamper resistance (§16.6.3 in the second edition).

Cloning a circuit is not easy in the first place: you need some moderately expensive laboratory equipment. Smart cards are designed so that you can't extract their data from just connecting to their designated input/output ports: you have to reach inside the package. Tamper-resistance techniques, which you'll find at least in the more expensive smartcards (the ones used for credit cards tend to be more secure than more basic uses such as building access badges):

Random glue logic: randomizing the physical layout and adding extra circuits that don't contribute to the logic, to make reverse engineering the circuits harder.
Packaging made of chemical susbtances that cannot easily be peeled off, the idea being that stripping off the packaging is likely to damage the chip as well.
Self-tests in software that disable the card if something unexpected happens, which makes active attacks (that perturb the execution) harder to pull off.

The equipment cost for a bench to run active physical attacks on a smartcard ranges from $10K for a basic probing station (capable of probing the less resistant models) to “a year's delay, a budget of over a million dollar, and no certainty of success” (cost estimates by Ross Anderson).

Physical tamper resistance is usually not the weakest link in the chain. A lot of attacks are of one of two kinds:

Combined logical and physical attacks: observe the behavior of the chip in certain conditions. For example, measure the timing, the power consumption (including DPA) and the electromagnetic radiation emitted by the card. These are side channel attacks, often combined with execution perturbation (observe the chip while under unusual conditions such as extreme temperature, or bounce a laser to cause abnormal execution).
Countermeasures involve a combination of hardware and software. For example, cryptographic primitives are implemented in such a way that the power consumption profile of a cryptographic primitive does not depend on the key. The code contains self-check that abort the execution or return safe wrong results (denying the transaction) or even mute the card if the hardware is not behaving as it should.
Attacks on protocols, not on the card itself. The attacks on EMV published by Anderson and others are of this kind.


bruteforcing .exe applications

You mean fuzzers?  Password list crackers? Program flow analyzers?

Yes. There are. And unless you build in proper (NOT self-rolled) cryptography, you need none of them: a simple debugger, which exists for all operating systems and is an absolute standard tool, can be used to extract the checks you're doing on the input, and just "bend" program flow so that the program just ignores what you enter and does what it would do when you enter the right passwords.

Seriously. Your exe isn't in your control. The only way to disable access to someone who isn't in possession of a secret is to encrypt whatever you want to protect with exactly that secret (either directly, or by encrypting a key with that secret), or to not store the protected thing with the exe but only deliver it from your server, which you do control.

In essence, you must never assume your executable code on someone else's computer is behaving like you've programmed it. Doesn't matter whether it's HTML+JavaScript, Delphi, C++ or assembler. It's running on a machine that you do not control.


How do I prove that robots.txt was not provded

robots.txt means nothing
The Simpsons explain it pretty well:

robots.txt is not an "access restriction", but instead merely a polite request to a complying web crawler not to index something. A web crawler can simply disregard this file and index whatever it wants anyways.
If you want to be sure, simply send them an e-mail and ask for permission. Or you know, just do it. A web-crawler that runs once an hour and does a few hundred requests with one request per 500ms won't disturb any server.


What happens if an OpenPGP subkey gets compromised?

If a subkey gets compromised, is it possible for the thief or whatever to [...] discover my password?

The passphrase is used to encrypt the private keys (both primary and subkeys) using a derived session key and symmetric encryption. The symmetric encryption algorithms used by OpenPGP are all strong considering known plain text attacks; thus when the attacker only gets hold of the unencrypted private key, he will not be able to conclude back to the session key, nor the passphrase.

  That happening, I would have to change the password of my primary key, right?

Probably an attacker will rather also get hold of the passphrase. This obviously means he will be able to decrypt the other private keys in case he gets hold of a copy encrypted with this very passphrase (so without any surprises, changing the passphrase after the keys have been compromised will not bother an attacker at all, as he already has copies of the keys encrypted with the old passphrase).

So yes, changing the passphrase might be reasonable, but also make sure to verify whether the attacker might have got hold of copies of your primary key encrypted with the old passphrase. If so, consider your primary key compromised and better revoke it, either.

  If a subkey gets compromised, is it possible for the thief or whatever to revert my subkey [...]?

Getting to the most relevant part of your question: subkeys can only be used for their very specific purpose, usually signing (documents, messages and code), encryption and/or authentication. Subkeys are never allowed to perform certifications (signatures on keys); this includes those on other's keys, but also on your own keys. Given the fact that all key management operations like issuing new subkeys, user IDs, changing revocation dates, revoking keys, ... includes issuing self-signatures, this means an attacker getting hold of your subkey cannot change your keys (not even revoke the subkey), he can only use the key for the purpose it was created for.

Revoking the subkey is another self-signature issued by the primary key, so even if you lost control over the subkey, you can still revoke it (given you have access to the primary key).


Is disaster recovery a requirement for any and every application that uses any ePHI?

First, I am not a lawyer, and this is not legal advice. Seek a qualified lawyer's advice before implementing any solution.

The intent of the availability rule is to make sure your patients always have the best possible chance for full access to your services. So if this is truly not "mission critical", it wouldn't be patient specific. If that's the case, I would work hard to de-identify the data so that it's no longer covered by HIPAA rules. Then it becomes a non issue.

If this is a patient specific process, then it's a service you are bound to provide, and I think it falls under the rule.

The problem is even if this tool is  "just an optimizer", your patients may become dependent upon your improved processes and response times.  That extends to response times for adjudication and billing activities, too. You might get away with it if you publish an SLA that encompasses your slowest possible response times. So if the optimized function normally runs in one second, and your unoptimized function runs in ten seconds, publish an SLA of 15 seconds, which would cover both.


You should start by setting up your WIFI card to monitor mode on the right channel (it will help airodump-ng find the packets):

airmon-ng start <interface> <AP channel>

After that, the command that you are using is indeed the correct one. I mean, you are using the AP MAC address, right? You can use the -a parameter, it will display only associated clients.

airodump-ng -c <AP channel> -a --bssid <AP MAC> -w <capture_file> <interface>


The article in Wired has a little more information.

The social network says its investigation into the breach began on September 16, when it saw an unusual spike in users accessing Facebook. On September 25, the company’s engineering team discovered that hackers appear to have exploited a series of bugs related to a Facebook feature that lets people see what their own profile looks like to someone else. The "View As" feature is designed to allow users to experience how their privacy settings look to another person.
The first bug prompted Facebook's video upload tool to mistakenly show up on the "View As" page. The second one caused the uploader to generate an access token—what allows you to remain logged into your Facebook account on a device, without having to sign in every time you visit—that had the same sign-in permissions as the Facebook mobile app. Finally, when the video uploader did appear in "View As" mode, it triggered an access code for whoever the hacker was searching for.


Is there a way to save state in burpsuite without logging sensitive fields like password?

Not without a lot of manual effort.

But the fact that you have to use personal accounts is the actual problem. Whenever you test an application, demand a dedicated test account (preferably one per role). That way, the burp state can be shared without any problems.

If you absolutely have to use personal accounts for some horrible reason, you will have to remove every mention of your passphrase from the burp state before sharing it. This may be tedious, depending on how the application works. If it's HTTP Basic Auth, which shares the plaintext credentials every time, you may as well not share the burp state at all and just copy individual requests.


Why is SUID disabled for shell scripts but not for binaries?

There is a race condition inherent to the way shebang (#!) is typically implemented:

The kernel opens the executable, and finds that it starts with #!.
The kernel closes the executable and opens the interpreter instead.
The kernel inserts the path to the script to the argument list (as argv[1]), and executes the interpreter.

If setuid scripts are allowed with this implementation, an attacker can invoke an arbitrary script by creating a symbolic link to an existing setuid script, executing it, and arranging to change the link after the kernel has performed step 1 and before the interpreter gets around to opening its first argument. For this reason, all modern unices ignore the setuid bit when they detect a shebang.

One way to secure this implementation would be for the kernel to lock the script file until the interpreter has opened it (note that this must prevent not only unlinking or overwriting the file, but also renaming any directory in the path). But unix systems tend to shy away from mandatory locks, and symbolic links would make a correct lock feature especially difficult and invasive. I don't think anyone does it this way.

A few unix systems implement secure setuid shebang using an additional feature: the path /dev/fd/N refers to the file already opened on file descriptor N (so opening /dev/fd/N is roughly equivalent to dup(N)).

The kernel opens the executable, and finds that it starts with #!. Let's say the file descriptor for the executable is 3.
The kernel opens the interpreter.
The kernel inserts /dev/fd/3 the argument list (as argv[1]), and executes the interpreter.

All modern unix variants including Linux implement /dev/fd, but most do not allow setuid scripts. OpenBSD, NetBSD and Mac OS X support it if you enable a non-default kernel setting. On Linux, people have written patches to allow it but those patches never got merged. Sven Mascheck's shebang page has a lot of information on shebang across unices, including setuid support.

In addition, programs running with elevated privileges have inherent risks that are typically harder to control in higher-level programming languages unless the interpreter was specifically designed for it. The reason is that the programming language runtime's initialization code may perform actions with elevated privileges, based on data that's inherited from the lower-privilege caller, before the program's own code has had the opportunity to sanitize this data. The C runtime does very little for the programmer, so C programs have a better opportunity to take control and sanitize data before anything bad can happen.

Let's assume you've managed to make your program run as root, either because your OS supports setuid shebang or because you've used a native binary wrapper (such as sudo). Have you opened a security hole? Maybe. The issue here is not about interpreted vs compiled programs. The issue is whether your runtime system behaves safely if executed with privileges.

Any dynamically linked native binary executable is in a way interpreted by the dynamic loader (e.g. /lib/ld.so), which loads the dynamic libraries required by the program. On many unices, you can configure the search path for dynamic libraries through the environment (LD_LIBRARY_PATH is a common name for the environment variable), and even load additional libraries into all executed binaries (LD_PRELOAD). The invoker of the program can execute arbitrary code in that program's context by placing a specially-crafted libc.so in $LD_LIBRARY_PATH (amongst other tactics). All sane systems ignore the LD_* variables in setuid executables.
In shells such as sh, csh and derivatives, environment variables automatically become shell parameters. Through parameters such as PATH, IFS, and many more, the invoker of the script has many opportunities to execute arbitrary code in the shell scripts's context. Some shells set these variables to sane defaults if they detect that the script has been invoked with privileges, but I don't know that there is any particular implementation that I would trust.
Most runtime environments (whether native, bytecode or interpreted) have similar features. Few take special precautions in setuid executables, though the ones that run native code often don't do anything fancier than dynamic linking (which does take precautions).
Perl is a notable exception. It explicitly supports setuid scripts in a secure way. In fact, your script can run setuid even if your OS ignored the setuid bit on scripts. This is because perl ships with a setuid root helper that performs the necessary checks and reinvokes the interpreter on the desired scripts with the desired privileges. This is explained in the perlsec manual. It used to be that setuid perl scripts needed #!/usr/bin/suidperl -wT instead of #!/usr/bin/perl -wT, but on most modern systems, #!/usr/bin/perl -wT is sufficient.

Note that using a native binary wrapper does nothing in itself to prevent these problems. In fact, it can make the situation worse, because it might prevent your runtime environment from detecting that it is invoked with privileges and bypassing its runtime configurability.

A native binary wrapper can make a shell script safe if the wrapper sanitizes the environment. The script must take care not to make too many assumptions (e.g. about the current directory) but this goes. You can use sudo for this provided that it's set up to sanitize the environment. Blacklisting variables is error-prone, so always whitelist. With sudo, make sure that the env_reset option is turned on, that setenv is off, and that env_file and env_keep only contain innocuous variables.

All these considerations apply equally for any privilege elevation: setuid, setgid, setcap.

  Recycled from https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts/2910#2910


using two passwords for normal and security critical functions

Not really, if you want to implement a function where the administrative functions require stronger authentication you should opt for two factor authentication rather than two passwords. The reason for this is that if an attacker can get your password somehow, chances are they can also retrieve the second one.


"Is is necessary to encrypt the message digest?" and

"Is it necessary to encrypt the hash of the message?"

Yes, since otherwise:
An eavesdropper could determine, with overwhelming accuracy, which pairs of [core ciphertext + hash] pairs are for the same message.  (The following three sentences wouldn't apply if you used a MAC instead of a hash.)  An eavesdropper could test any guess at the message on their own.  If you use CTR mode, then an adversary who knows the plaintext could modify a [core ciphertext + hash] pair to yield any plaintext of their choice.  If there is a secure encryption scheme, then there is one for which your

approach would allow an adversary to generate [core ciphertext + hash] pairs that will decrypt

to arbitrary plaintexts even without having seen any legitimate [core ciphertext + hash] pairs.

"Can't we send the encrypted message along with the unencrypted message digest?"

You could "send the encrypted message along with the unencrypted message digest";

however, that would be even less secure than what you're doing.

Your approach is not secure.

See Authenticated Encryption vs. contained and encrypted checksum/hash?

and Should we MAC-then-encrypt or encrypt-then-MAC?.


How can I recover my encrypted data from a Sandisk Secure Access

The downside to encrypting your data, is that if you lose your password, and it wasn't an easy one; it's pretty much game over.

As you made the password (you did, right?), try any password you ever made. If that fails, try using a script that brute forces the top 10 000 most used passwords, there are password lists scattered all over the itnernet. If that fails your last resort may be to brute-force the password, Kali Linux has lots of great offline password cracking tools.

Note: Brute-forcing passwords can take a LONG time (we're talking anything from an hour to 300 billion years if you have a decent password) if your password is anywhere above 5-6 characters. You can test how long it would take to bruteforce a certain password on this website: www.howsecureismypassword.net.


you can  try  CyperChef

https://gchq.github.io/CyberChef/

you can easily try different N-bases decryption  & others


Wireguard: Is it suitable for road-warrior scenarios?

Yes, WireGuard does an extremely good job at preserving your connections even if your local IP keeps changing. Wireguard connections are also super fast to establish, such that if you suspend your laptop and then resume later, your wireguard VPN connection will be immediately available without having to do anything on your part.

Whether it is easier to set up is more difficult to judge, as "easier" is a very relative term. GUI tools for wireguard are still missing from many distros, so the most straightforward way to set up your wireguard VPN is using command-line. Mullvad provides a few handy guides (and they also are one of the very few commercial VPN providers offering wireguard support):

https://mullvad.net/en/guides/category/wireguard/


Why does Kaspersky warn me about PHP trojans on a Mac?

PHP being a scripted language needs to be interpreted and run by the script interpreter.

Its like downloading a malicious VBScript or bash script, until you execute it, by passing the script to the interpreter, it remains benign.

Can you provide more details as to what the AV detects? It usually gives a value like Trojan.WXYZ which then links to a website where more information is included.

Caveats: This is assuming there isn't another exploit at work, for example the windows exploit where a malicious .lnk file would be executed simply by viewing it in explorer.


Storing encryption keys on a server using Node.js and MySQL

Hopefully I am understanding this properly. Client sends message to server over SSL encrypted connection. Server gets the message and stores it in a database. You are worried that if someone breaks into the server, they can read the database and see all the messages.

So, encryption seems like a natural fit. Encrypt the messages (each with a different key) before storing them in the database. The problem now is, what do to with the keys. You can't just store them on the server as the attacker is on the server. They can easily find the keys, pull the entire database and decrypt everything.

It would appear your best options are storing the keys on a different machine and let that machine do the encryption/decryption. That way the attacker would first have to break into your machine, then into the encryption/decryption machine. Not impossible, but hopefully much harder.

Another option would be some cryptographic hardware. This is beyond my expertise, but companies sell hardware that performs cryptographic operations including key storage, encryption and decryption.

Here is the tricky part. What stops the attacker from querying the other machine or the cryptographic hardware repeatedly until he has decrypted all the messages? You'll have to build some sort of detection on there or something like that.

In short, given your adversary model (attacker with root privileges on the box), the problem is pretty hard. Hopefully one of these two options will be useful to you, or at least generate some other answers.


Can a Government Intelligence Agency See *Who* I Am Messaging On WhatsApp

Yes, says Forbes:

  Hence one order (published below) sent to WhatsApp in May 2016, a month after the full rollout of end-to-end encryption was complete. [...] The date, time and duration of comms would be recorded, as would the numbers involved.

However, this article on Softpedia indicates that historical metadata is encrypted:

  As it stands right now, if the FBI would want access to any encrypted WhatsApp data or metadata, Facebook looks poised to put up a fight, just like Apple.

WhatsApp necessarily has the metadata of who communicates with whom, and being a US company they have no choice but to cooperate with warrants that order them to turn over the data.

Note also that metadata is enough to get a conviction. From BBC:

  Sterling was convicted for the most part entirely on phone and email records with no content attached.


Any difference between these certificates from a security perspective?

All X.509 certificates used in TLS certify the same sets of data.  The security of the certificate is bounded by the key size and type (which you pick when you generate the private key) and the key size and type and signature algorithms used by the certificate authority to sign it.  Provided all of the keys and signature algorithms meet your desired security level and certify the domains and IP addresses you wish, there is no difference in them.
The relevant difference appears to be different levels of "assurance", whatever that means.  Since these are domain-validated certificates and the CA/Browser Forum specifies the approaches that may be used to securely validate a domain, there is no reason to believe that one of these is better than the other, except possibly for the pocketbooks of the sellers.
Do note that Let's Encrypt offers free 90-day wildcard certificates through automated issuance via the ACME protocol, and so unless you need a longer lifetime or a feature Let's Encrypt doesn't support (e.g., IP addresses or ECDSA roots), you can end up paying nothing at all by going with them.


According to github discussions 1 these urls (with the xts param, which is an abbrivation for eXtensible Time Series 2) are likely to track activity. The long string is a unique identifier of the post.


Can the MAC address be "hidden"? ie that the information is not even delivered

Changing an interface's mac address is not terribly difficult at all.

You can also change the MAC address through various other methods, such as a VPN, or on VirtualBox. Not all of these methods will allow you to change your router's MAC address. You should have a MAC for each interface on your network. Many newer routers have more than one interface (wired, wireless, and router, for example).

But is changing your MAC address the answer?

As for hiding your router's MAC address, be warned: many ISPs require your device's MAC address before they even allow you to connect to the internet. And even if you spoof it before providing the spoofed address, that is the address they expect you to be connecting from.

There are legitimate uses, such as spoofing a new router's mac address so you don't need to bother with calling customer service in order to get online.

If I'm understanding you correctly, you want to mask your presence.

If you wanted to "hide," you'd need to change every single interface's MAC address. And even then, you can't really hide this way: the router is still tied to your name.  If you intend to "hide" using a mobile device, that is far more feasible. Just google "change mac address devicename". However, there are many other things you need to do to properly mask your presence. This is beyond the scope of my answer.

Can you change your MAC address to anything you want?

  Moreover, can it be replaced by a casual sequence or there are specific addresses to use?

No. It has to be an appropriate mask and length. Usually, you need 12 Hexadecimal digits, and the 2nd character can't be odd if it's unicast. For example, if unicast, the 2nd "digit" can't be any of the following:

Digits: 1, 3, 5, 7, 9
Letters: B, D, F

  Finally, once changed, can it be reset to the default value?

If you're able to change it, then you should be able to change it again. Just set it back to what it was before.


Consequences of putting a serial number into an AES key

There are no known attacks on AES that let an attacker turn partial knowledge of the key into full knowledge.  If 16 bits of the key are easy to figure out, then you've got what is effectively a 112-bit key.


Pay attention to the clues you see in the output and start eliminating possibilities.

The latency to this target is 0.000077s, or 77 microseconds. I observe my wireless gateway to have a latency of 0.013s to 0.10s, 3 to 4 orders of magnitude slower. A localhost scan shows something like what you got: 0.000065s to 0.00018s. So this IP is likely running on your own system somewhere, perhaps virtualized.

Change the state of your network and see how the target responds. Unplug your network cable and/or disconnect from your wireless network. Does the IP still respond?

How is the packet getting to the target? Examine your routing tables (netstat -rn or route -n) or ask Nmap what it is doing: nmap --route-dst 192.168.2.137. Is it using a gateway address? Do you have a 192.168.2.0/24 address configured on your system?


Is there any way to get Chrome 27 to trust a self-signed cert?

So it turns out that Chrome won't trust names that aren't fully qualified. I was working with a host name of "foo" which was fine in IE once the cert was in the list of trusted roots. I created a new cert for "foo.com", repeated exactly the same process and now Chrome is happy.


In Login page of web application, I have allowed drag and drop of any text. Is it vulnerable to XSS attack?

An XSS attack is performed by injecting malicious code to be displayed to another user.

To use a standard login form for an XSS attack, you would need the malicious code to be in the username - the only thing likely to be shown to other users.
But how the username-with-malicious payload got in there isn't relevant, so it is not inherent to the fact that you use drag-and-drop.

Allowing a username that consists of a large amount of text (for example, the contents of a file) would make it easier to perform this type of XSS attack in a username. So you'll want to check the username against it.

That being said, usernames are often limited in the length they're allowed to have. This makes them unlikely attack vectors. If you're running some kind of forum, users signature lines and forum posts are more likely places to contain an XSS attack.


To send that email, the server needs to fetch the email adress from the database. It probably does something like this:

$sql = "SELECT email FROM users WHERE username = '$username'";

You could try to make it email yourself instead by injectin some SQL into $username:

do_not_exist' UNION SELECT 'me@example.com' FROM dual --

But if you got a password reset link, it probably would not be for the admin user. Hmm. Perhaps you could use the email adress itself to exfiltrate some data?

do_not_exist' UNION SELECT password + '@example.com' FROM users WHERE username = 'admin' --

Now you just wait and see what email address get an email. The risk here is that the script also tries to insert a row with the username and the password reset token into some table. If that is done before the email is sent, and that query is also vulnerable, this might just crash the script. But it's worth a try.


This isn't completely useless.  It does provide one bit of protection: an attacker who steals the value of authKey for some session only gets to exploit it for a very narrow time window.  In fact, what your coworker is doing very much resembles TOTP—the familiar system of time-based six-digit codes used as a second authentication factor.

Here's one scenario: an attacker manages to steal log files that reveal authKey values.  Without the timestamp thrown into the mix they could just reuse that value, possibly indefinitely.


Crypto++ RSA - Encrypt and sign with the same key pair

I can answer your first question. It's not recommended to use the same RSA key pair for signing and encryption. The reason for that may be differences in expiration or key-escrow (e.g. sometimes organizations will want to back up your encryption key (confidentiality), but you do not want them to have your signing key(non-repudiation)). There's also a long shot possibility that if you blindly sign messages without checking or hashing the message a user can decrypt the message (signing applies the private key on a message). This is quite rare and would result from atypical application development that has bad design anyway.

Also, if you can manage one key, why not two?


If non-repudiation is impossible why do digital signature exist

Digital signature can indeed provide non repudiation, provided that the procedure used to sign the certificat:

ensures that the private key was at any moment under exclusive ownership of its recipient
(optionally) ensures that the signed cert was given to the right person

As soon as 1 is established, the certificate authority can attest they actually signed a certificate for the key used to sign, and that the message could only be signed by the owner of the certificate - but she is unknown to that point
If in addition 2 is established, the certificate authority can attest that the private key used to sign the message was owned by M. X . That is an evidence that actually proves that M. X did sign the message or at least is responsable for it if he did not declare that his cert has been compromised before the message was signed.