Is the aggregate severity rating of "Important" for MS13-027 too low? The Security Bulletin states that the "Maximum Security Impact" is "Elevation of Privilege"; however, the SRD blog post says code execution is possible. Additionally, SRD says "Other software that enables low-level pass-through of USB device enumeration may open additional avenues of exploitation that do not require direct physical access to the system".
Further, the March Summary indicates that an exploit is likely for this vulnerability.
Given all of this, how is the "Aggregate Severity Rating" not Critical?
Once scenario that I'm now worried about is the maid walking around at night, owning all of the desktops on my trading floor, or any other Windows based corporate device.

EDIT: Here is the white paper the researcher published on the topic of USB.

I'd say that as @AJHenderson says their rating of Important is down to the requirement for physical access.

That said as with any vulnerability the actual risk to an environment needs to be assessed based on the likely threats to systems and their accessibility.  In some companies the risk of this attack will be quite low (e.g. datacentre environments where physical access to systems is extremely limited), whereas in others it will be high where access is easy (e.g. any kiosk style environments that allow USB access) or where likely threat actors can get physical access to systems (e.g. financial organisations who may allow contract staff like cleaners physical access to systems (think sumitomo bank))

Ultimately I'd say that the Microsoft rating should just be seen as a starting point for a companies risk assessment and they need to take account of their own environment before deciding on how severely to treat a given issue.


Can I use the same ssl cert to protect my web site and sign my app? I'm considering buying an SSL cert from my web host provider (smarterasp.net)

They list the cert as :

  SSL-S    Comodo SSL Certificate - Single Domain or Subdomain

Do you know if I can use that same cert to sign my .NET app so it will no longer be flagged as dangerous when it is installed on Windows?

I see they also list other certs for purchase which look like:

  SSL-E  Comodo SSL Certificate - Extended Validation(EV SSL, Green Bar)
  SSL-W  Comodo SSL Certificate - Multiple Subdomains(*.yourdomain.com)

Would any of these work for dual purposes?   Or, are those two things (web securing and app signing) just completely different things to be purchased separately?

No.

The long version follows. I simplified a few things, so don't take every single statement as gospel, but the basic principles are correct.

You can't use the same certificate. You may be technically able to use the same private key, but it won't make your life easier and it would be bad for security.

From a technical point of view, the operations involved in securing a TLS connection and in signing some code for distribution are the same. Your server stores a private key, which nobody else knows. The server uses this private key to sign a {TLS connection handshake message}/{zip file containing your code}. Anybody who receives the signed data can verify that it was signed by someone who knows the private key corresponding to a certain public key K.

They know that the holder of the private key corresponding to K has signed something, but this is not useful unless they also know that you are the holder of this key. A certificate authority issues you a certificate, which says: ”I, undersigned, certificate authority, guarantee that raddevus.com is the holder of the private key corresponding to K“. Only, they say it in math and X.509 rather than in legalese. All this business of saying (in cryptographic language) who someone else is is called a public key infrastructure (PKI).

In addition to establishing a link between "raddevus.com" and K, the certificate states a number of restrictions on its usage. A certificate without restrictions could be dangerous. For example, this certificate doesn't allow you to, in turn, say, “I, undersigned, guarantee that google.com is the holder of the private key corresponding to K”. Well, you can say it, but browsers won't believe you, because your certificate doesn't allow you to make such claims. In technical terms, your certificate doesn't allow you to be a certificate authority. Your browser trusts the certificate authority when it claims that you are raddevus.com because its own certificate says that it's allowed to make such claims, and the reason it can get such a certificate is that it's satisfied the the certificate authority authorities. And your browser has a built-in list of certificate authority authorities that it's willing to accept.

You can look at what's inside a certificate to get a feeling. Modern browsers have an interface for this. In Chrome, open the developer tools and go to the “Security” tab. In Firefox, click on the padlock icon in your browser and follow the directions, e.g. click the padlock then “> (Follow connection details)” then “More Information” in Firefox. Navigate to the certificate details. Let's take https://www.smarterasp.net/ as an example; some highlights are:

The “Subject” field lists *.smarterasp.net. This is the website(s) that the certificate is valid for. If the website responded to requests for https://notsmartasp.example.com/ using this certificate, a browser would close the connection because the certificate is not valid for that host name.
The “Certificate Subject Alt Name” field also lists *.smarterasp.net, and smarterasp.net. This is the modern way of defining names, not supported by antique browsers.
The “Certificate Basic Constraints” field states “not a certificate authority”. It also says “Critical”, that only means that an application that doesn't understand what a “Certificate Key Usage” is should treat the certificate as invalid; “Not Critical” would tell such an application to ignore the field.
The “Certificate Key Usage” states “Signing” and “Key Encipherment”. If the server tried to use the key for something else, applications that use the certificate to verify something should reject it.
The “Extended Key Usage” states “TLS Web Server Authentication” and “TLS Web Client Authentication”. (These are the English translations of the ASN.1 OID 1.3.6.1.5.5.7.3.1.) This is more precise than “Signing” from the other key usage field.
Up above, the “Certificate Hierarchy” shows the chain from the trusted-by-your-browser certificate authority authority, down to the CA and the website.

If you want to sign some code, you need a certificate whose extended key usage includes the OID 1.3.6.1.5.5.7.3.3, which in English is known as “Code Signing”. To do this, follow the steps described in Microsoft's documentation. If you want to know more about how these tools work (I guess you do, or you wouldn't be reading this), read the old instructions. Note that the documentation mentions the requisite extended key usage (they call it “enhanced key usage”, but it's the same thing). The documentation also mentions a few other constraints on the certificate.

If you want to go further and establish the link between that certificate and raddevus.com, you need to get it signed in the Microsoft application distribution PKI, rather than in the TLS PKI. I'm not familiar with this PKI, I don't know how you get into it. I think it involves going through an application store.

While you may in theory use the same private key and generate different certificates from it, one for the web and one for code signing, it would be more work converting between formats than generating two keys. And using the same key would be a bad idea for security. Your web server's private key has to be on the web server because it is needed on each connection (to authenticate the website to the browser). On the other hand, your application signing key only needs to be used when you deploy a new release version of your application. If your server gets breached, you need to revoke its key, get a new one, and people attempting to visit your website and being attacked by a man-in-the-middle (who redirects connections that should go to your site, to their own site) will suffer. If your code signing key is compromised, then until people receive the revocation information, they will be at risk whenever they receive an application package signed with your key; that attack (distributing a dodgy executable) is rather easier to arrange than a man-in-the-middle. So you really should protect your code signing key better than your website authentication key.

Note that you can get a website .


How to avoid leaking your public IP to installed applications like browsers when using a vpn? What is the easiest setup to hide your public IP from installed applications and prevent things like WebRTC leaks on a common Linux distro?

How to prevent WebRTC leaks? Disable it. There are browser extensions that can help toggle it.

Otherwise, you'd need to create firewall rules that ensure 100% of your traffic goes through the VPN, including blocking all IPv6 if the VPN doesn't support it.


Is the newly adopted NFC technology going to be safe? I got sent a link today talking about how the business card company "Moo" is implementing a chip into their cards that will allow NFC connections to do many things such as share contact info, open a website, open a social media page, etc etc.

So I personally don't know a ton about NFC or the connection it establishes, but to my knowledge all it is, is a radio connection. So once the chip and device realize they are connected it runs a command, probably something like

if device=connected{
do this
} else {
end / don't run command
};

I was wondering, just how secure can this connection be? Just off the top of my head I feel like it poses a major security risk to a couple threats, just a list I thought of:

You tap the card and:

The chip installs software (keylogger)
The chip steals something (Apple keeps your payment info in general settings of the app store)
The radio signal is intercepted by a third party

How possible are these scenarios? Should anyone be concerned with using the new NFC cards?

(Sorry not really sure what to tag this)

NFC is just another medium like wires, wifi, microwave, light-comms, etc. It will be incumbent on the security professionals to create and guide their safe use whether it is for payments, data sharing or any other purpose.

Being an invisible medium probably brings its own risks in terms of awareness, but there is nothing intrinsic beyond its invisibility that suggests it will be any more or less secure as a medium.

As for your scenarios, I don't think the medium is relevant, only the systems that use the medium and they will depend on secure design, architecture and implementation like any other.

People have been talking about this issue for some time now in a security context and awareness is definitely growing.


What level of compliance do I need as a software vendor? I am having a bit a difficult time trying to assess to what level my business needs to be PCI compliant.

My business is developing eCommerce websites that are hosted by the client. The websites have an iFrame on the checkout which links to the payment gateway application that takes and processes the payment information. This payment gateway application is also developed by my business and handed over to the client who is hosting it on a PCI compliant server that my business does not have access to.

As my business is only providing software development services I was always under the impression that we don't need to be PCI compliant. However, my clients believe that I am falling under SAQ D.

I went through SAQ D but as my business is not in charge of hosting any of the applications I am struggling to fill in the questionnaire.

Does my business require PCI compliance? And if yes, what is the correct questionnaire?

Any help is appreciated!

Edit: This actually is unlikely to be correct.  See dave_thompson_085's answer about the PA-DSS instead.

Original answer:

Unfortunately, you do need to be PCI compliant, as a SAQ-D Service Provider.
Here is a link to the official PCI Quick Reference guide.  Some quotes:

  The standards apply to all entities that store, process or transmit cardholder data – with requirements for software developers and manufacturers of applications and devices used in those transactions.  [page 6]

  The PA-DSS is for software vendors and others who develop payment applications that store,
  process or transmit cardholder data and/or sensitive authentication data as part of authorization or settlement, when these applications are sold, distributed or licensed to third parties. Most card brands encourage merchants to use payment applications that are tested and approved by the PCI SSC. [page 7]

Think of it this way: If your network gets compromised, no one gets cardholder data.  But a vulnerability could be inserted into your application without you being aware, which would then be distributed to all your clients.  (This is known as a supply chain attack.)

This page even explicitly calls it out:

  However, not all organizations recognize their role as a service provider, and this lack of awareness puts their business—and their customers’ businesses—at risk.  The last part of the service provider definition (“also includes companies that provide services that control or could impact the security of cardholder data”) is what often causes confusion.  If a company offers, for example, a managed network firewall, and their customer uses that firewall to protect their point of sale systems and back office computer that make up their card data environment, then they absolutely can impact the security of card data.

  Examples of service providers that often don’t know they are service providers include hosting, billing account management, back office services and co-location providers, just to name a few.

I haven't had to fill out a SAQ-D SP myself, but I believe you should be able to mark large swaths of it N/A (with supporting explanation in appendix C).  For example:

  The questions specific to application development and secure coding (Requirements 6.3 and 6.5)
  only need to be answered if your organization develops its own custom applications.  You would need to fill out these sections, since you're developing software.
  The questions for Requirements 9.1.1 and 9.3 only need to be answered for facilities with
  “sensitive areas” as defined here: “Sensitive areas” refers to any data center, server room or any
  area that houses systems that store, process, or transmit cardholder data.  You could N/A this section, since you aren't touching the data yourself.

As always, I am not a QSA.  You should probably consult with one to confirm/help define what you need to assess, rather than relying on one random person on the internet.  This should get you started, though.


is there a way to indirectly uncharge rapidly a coin cell to defeat an anti tampering mechanism? An anti tampering mechanism of a device relay on detect tampering mechanism when the device is powered down using the energy provided internally by a coin cell.

Is there a way to uncharge rapidly a coin cell contained in a device without having access to the coin cell and the electronic that use it ?

I'm trying to thinking out of the box (probably in a stupid way). What about ?

microwave effect
high/low temperature
increase/decrease humidity
?-ray from a medical equipment

In order to rapidly discharge a battery the energy has to go somewhere. You would have to either physically contact the coin cell and cause a drain, or somehow cause the electronics to do it for you. Whether the electronics would have the capability to cause that drain is another question. Most devices are designed to conserve the power of their backup batteries so my guess would be a no.


How (in)secure is POP/IMAP/SMTP I'm making a few assumptions about basic email security, and I want to confirm or clarify some of these points to make sure I understand the big picture. Please correct me where I'm mistaken:

The answer to this question gives some insight, but doesn't cover all I'm looking for.

This is all assuming a traditional email service, accessed using a desktop or mobile client, over POP or IMAP, and SMTP (ignoring webmail).

Suppose I'm retrieving messages - my client app passes my username and password to the POP server, which authenticates me, and sends back the messages. If I'm not using SSL/TLS, then the entire conversation, including the message and credentials, is in plaintext. And anyone watching the network traffic can intercept the entire thing. And if I am using SSL, then the entire conversation is safe, even over a public network. Do I have that right?

My understanding is that traditional messages are insecure when my server talks to someone else's server - so the message itself is likely vulnerable while in transit between servers, but at least with SSL my email password would be safe.

If I understand, PGP or similar would mean that the message itself is encrypted, so that as long as my and the recipient's private keys are safe, nobody else could read the message. But that's just the message, right? Not the IMAP/SMTP/POP connection? Meaning if I used PGP for the message, but a non-SSL connection to SMTP, I'd still be sending plaintext username and password to authenticate.

Basically, I'm trying to understand why an email provider would refuse to offer SSL/TLS for POP/IMAP/SMTP connections - one particular provider says they don't do it because email is inherently insecure anyway, so SSL doesn't actually do anything to protect you, and they suggest PGP for truly secure email. I'd like to argue that while SSL may not be end-to-end message protection, it would at least protect my credentials and protect my message for a significant portion of its journey (me to SMTP server, and POP server to recipient assuming they're connecting with SSL).

Do I have everything straight with that?

To answer your question:

If you're using SSL/TLS to access your e-mails, regardless of whether it's POP or IMAP then it would be very difficult for anyone to decipher the text of the e-mails from analysing the traffic alone. That said some large companies e.g a law firm I used to work for have a server which sat between us and the internet, stripping out the SSL so the answer is a qualified yes in saying you're safe.
Also if the message is still sitting on the e-mail server after you access it, then it is possible for your e-mail provider to be bribed/coerced into handing it over. Of course GPG does solve this problem. You can also ask your e-mail provider to delete messages you download through POP though you have to trust that they're both able and willing to delete the messages securely.
With SSL, when logging in using your e-mail password, your password cannot easily be read by intercepting the traffic between your computer and e-mail server subject to the proviso I mentioned in point one.
Your understanding of PGP is largely correct. If a message is sent to you encoded with your public key then only you our someone who has broken your private key can read it. The sender's private key is irrelevant as he can't use it to decode a message meant for you. If your e-mail password were sent in plain text though you're absolutely right in thinking it could be intercepted and someone could access your e-mails or send them on your behalf pretending to be you. If you used PGP at all times to encrypt and sign all messages and others did the same for you, this would protect the content of your messages though.
I can't imagine why an e-mail provider wouldn't want to offer SSL beyond sheer laziness. You can even get free certificates these days! Most of the free webmail providers offer SSL e.g Gmail, have you thought about using them?


In AWS EKS, how should Kubernetes certificates be generated? This article from 2018 states (emphasis mine):

  It is common practices for Kubernetes clusters to self-signed their digital certificates. I often get from Security Practictioners the hairy eyeball when this fact is discussed. Why not use “real” certificates, that are signed by trusted CAs. Well, some people do that, but for the rest of us, you are simply not gaining any signficant security benefits, and you are creating more work for yourself. You see, Kubernetes clusters use many digital certificates in all aspects of managaging a cluster. For example, each node has its own digital certificate to verify its authenticity.'[1]

Is it still the correct approach to just allow EKS managed Kubernetes to create and deploy its own certificates?

[1] https://www.nickaws.net/aws/2018/08/16/Verifying-digital-certificates.html

With Kubernetes in general, the certificates aren't actually "self-signed" so much as they're signed by an internally managed certificate authority.

Typically, one of the main points of signing a certificate is to ensure that the clients of that service can ensure the certificates validity. In the Kubernetes case this is handled by ensuring that the client has the CA cert on setup. So for example a kubelet on a cluster node will be given the CA cert file as part of setup so it can validate the certificate of an API server that it connects to.

For end users this certificate authority data is generally passed out as part of the kubeconfig file used to log in to the cluster.

So really complaints about "self-signed" certificates don't apply, either in general Kubernetes or EKS.  There are other problems with how Kubernetes manages certificates (e.g. lack of revocation support) but those aren't specifically related to this issue.


CSP: What is script-src-attr and script-src-elem? script-src-attr and script-src-elem directives are new additions in CSP3.
I am not able to understand how are they different from the script-src directive.

https://w3c.github.io/webappsec-csp/#directive-script-src-elem

This documents the new addition but I am not able to clearly differentiate between the usage, maybe due to hard language.

Script-src-elem works on script tags:

<script>alert(1)</script>
<script src="/jquery.js">

Script-src-attr works on attributes that contain JavaScript:

<svg onload="alert(1)">

More information can be found in the  Intent to Implement and Ship: CSP3: script-src-attr, script-src-elem, style-src-attr, style-src-elem directives


Steps to Harden Ancient Gaming Server I am somewhat administering an old Windows Server 2008 server that is used to host a older Video Game.

It's in such a state that it has tons of custom code on it that run the server and hasn't really been maintained.

We recently noticed that someone had taken control of and turned the box into a malware/spam box.

The box has internet facing RDP (yes I know...) and FTP.

What steps, if any, can I take to more secure this box and try to make it even a little bit harder to compromise?

Thanks.

While it is a bad idea to still keep the server running such old and unsupported systems are actually often found in industrial environments where they are used to run some software only supported on such older OS or which is tied to specific hardware.

The way to limit the risk in such cases is to minimize the attack surface as much as possible. This means removing or at least disabling any software and services which are not actually needed, harden any passwords in use on the system and put a firewall in front of it. The firewall should restrict access to only the applications which need to be actually accessible from outside and only for specific IP addresses. The firewall should also limit what traffic can leave the system so that a successful attacker will at least not be able to infect other systems from the compromised one. Of course you should not rely on the builtin-in firewall for this since the attacker might change this.

This way you at least reduced the risk of the system getting compromised and that it can be used to attack other systems after a successful compromise. Once this is done you should also look for a long term strategy to deal with the system, since what you did for now was only to limit the impact of the worst problems. Long term strategy might involve to declare the service you offer as officially obsolete so you can switch off the system after a while. Or you might rebuild everything in a more secure way on a supported platform and migrate customers to the new system.


Why do people use "burner phones" rather than Signal or similar solutions? Why do people use burner phones rather than Signal or similar? I would imagine that if you are high value target the police or intelligence service would simply eavesdrop every phone call passing the base station nearest the location where you dwell. Doing that then it is easy to filter out all phone calls made between phone numbers that have been used more than hundred times or for more than three months (or something like that) in both ends. The amount of remaining phone calls should minuscule, and there you have your criminal, spy or whatever speaking in cleartext on a non-encrypted line.

if you instead of using a dumb phone used something more modern you can on the one hand be exposed through a trojan or a rootkit but is that really a doable attack vector, even for very valuable targets?

If you use something like OpenBSD or one of the hardened Android phones that are on the market and only install Signal on it and then only use it for Signal. Never browse the web, never use it for regular phone calls and texts etc and keep it updated (Maybe regular factory resets too?), can the authorities, even if they have a lot of resources, really manage to sneak in some malware on it? Malware that can't be caught by another layer of security (E.g., your firewall could be setup to only allows device A to connect to internet to Signal destinations and ports using the Signal protocol - making it difficult to deliver whatever the malware manage to find to the people controlling it.).

What are the best practises for safe phone calls if you are a private citizen that some authorities are very interested in listening to?

People do use Signal, and even less secure systems like Whatsapp, to do the kind of communication that has traditionally relied on burner phones.

Let's dispense with the spy fantasies first, though: the majority of people who use or have used burner phones are not spies or high value targets,. As you can guess, not all criminals are technically-minded enough to use a software solution, and a low-tech burner phone is easier for many of them.

Nonetheless, encrypted messengers are getting increasingly more popular both in the scam business and in the retail drug business. Evidence to the former can be seen in many scam questions on Finance, to the latter in drug tags on the street with messenger names instead of phone numbers.

Both methods alone or even together leave a lot to be desired for perfection. Encryption can be broken with rubber hose methods and anonymity can be defeated by circumstantial evidence. In real life, perfection is not needed. Either the reduced detectability provided by encrypted messengers or the evidence loss/deniability provided by burners suffice to reduce the incarceration rate for their users.


What are the parameters to be logged in a web application? I am working on developing a secure authentication system  with SSO. Until now I have been using the logging framework to generate logs that help in debugging the application. I wonder if there is a guideline to implement logging in a web application.

for example let us say there is an attack on the web app and a security professional comes to analyze the logs then what are the things he will be trying to find out? How to make log analysis easier?

If it was me, I'd want the following:

Precise timestamp (at least 1 second resolution)
Source IP address.
Source port, if possible.
Full set of request headers, if possible.
Session ID.
Forwarder headers (e.g. X_FORWARDED_FOR) are mandatory for tracing through  non-transparent proxies.
Full raw requested URL.
POST parameters if applicable.
Any other data specific to your webapp that might be useful in tracking actions.

In some cases, this information might be bulky. By splitting the logs off daily and archiving them in a compressed format, it should be possible to store a reasonable history of logs. It would also be acceptable to strip out the more verbose information (e.g. full POST data) after a couple of weeks, but that may limit the effectiveness of incident response and forensics for attacks that are detected at a later date.


After performing a SSL strip, can you upgrade back to HTTPS with your own encryption from the proxy? Let's say you are performing a SSL strip. From what I can understand, it modifies either the client or server packets (in the http/https protocol), which indicate that it supports encryption to not supporting encryption.

I was wondering if it is possible during these exchanges to tell the server that the client is not supporting encryption, but then tell the client that it is, with goal of forging the packets so that the encryption protocol takes place between the proxy and the client.

Unless the attacker is able to install a new certificate authority (CA) at the users system he can not make the client visit the original site by https through the attacker proxy without the client getting certificate warnings. And, installing a CA just from inside the browser without any explicit user interaction is not possible.

The attacker could though change the target URL's within an SSL stripping attack not only from https:// to http:// like the normal sslstrip program does but could keep https:// and instead change the site which gets visited. For example if the attacker owns example.org he could change the access from https://example.com to https://example.org and mirror the original site at his attackers site. Many users would probably not notice such change and happily fill in credentials and similar.


Replace hashing function with asymmetric cryptography when password authentication I would like to know if the following ideas are feasible:
Hash function is one-way function.
Generate public key from private key is irreversible(asymmetric cryptography).
User password entry -> SHA(or adding salt before hashing) -> hash value(as ECC private key) -> generate public key from private key -> save public key(drop private key)
Password authentication:
User password entry -> SHA(or adding salt before hashing) -> hash value(as ECC private key) -> generate public key from private key -> verify the public key with the saved one.
Based on that:
a.User or others can encrypt selected information(by using public key) that only user can decrypt it.
b.System administrator can generate a public/private key pair then both user and administrator can encrypt/decrypt selected information(by using Diffie–Hellman key exchange method).
I think that brute-force method(exhaustive attack method) can crack any password, and it is only a matter of time.It should be an another topic.
I am trying to prevent user information leak or rainbow table attack even if system being hacked.
I have searched and read the following information:
https://crypto.stackexchange.com/questions/9813/generate-elliptic-curve-private-key-from-user-passphrase
Handling user login using asymmetric cryptography
Asymmetric Cryptography as Hashing Function

... hash value(as ECC private key) -> generate public key from private key

You are assuming that an arbitrary key (output of a hash) can be used as an ECC private key and that the public key can be derived from this. This is not how it works though. If you want to derive a key pair from an existing random string or passphrase you would need to use some deterministic random generator in the key generation process - see  How can one securely generate an asymmetric key pair from a short passphrase?.
If you see the conflict between the words deterministic and random in the last sentence you might realize that this is maybe not such a great idea to do. It should be doable though.
I'm pretty sure that there is a better way to solve the actual problem you have. But currently I see only particular technical aspects in your question and not a real description of the underlying problem you are trying to solve at the end, so it is hard to tell how a better approach to the (unknown) underlying problem would be. It might be useful though that you check (and document in your question) existing approaches to your problem in more detail first before determining that you need to invent your own approach - see Why shouldn't we roll our own?.


Obfuscation and Mobile App Recently, I stumbled with this topic in my mind for few days.

I understand that obfuscation is not the best protection against reverse engineering. I wonder if there is another method that make it harder for reverse engineering, especially in mobile apps.

In android environment, it is easier to reverse engineer an APK due to Java Nature. In IOS, I would care less about obfuscation, except for Jailbroken devices.

My question here:

Obfuscation is always reversible. Is there any method that can help
make it harder for reverse-engineering?
Does it help if we update
the APK with new released mapping obfuscation every month? How long
usually hackers will be able to reversed engineered obfuscated
APK?Let say that I don't really care about the code itself, but I
more concern with specific data that I may need to hard coded them
in APK.
Lastly, is there anything preventive action we can take with Jailbroken phone? For example, make the app is not downloable from app store if it is jailbroken.

It's harder to reverse-engineer complex code. You can introduce extra variables, pipe data through multiple classes, create classes which don't actually do anything, and generally muddy the waters. Measures such as this make it much more complex to reverse engineer your code, however it makes it much more difficult to engineer your code in the first place and keep track of changes. Here's a good article which may help
Yes, making frequent releases with substantial changes in your code makes the job of the attacker more difficult, and the developers' as well
A phone being jailbroken does not mean its security has been compromised by an attacker. Phones can be hacked in ways that are undetectable, so spending time preventing your app from working on a jailbroken phone is a waste of effort and is more likely to annoy the app's legitimate users


Socket closed depending on data. Am I facing an active firewall? (DPI - Deep Packet Inspection) Following my troubleshooting of making a TLS connection (See: Testing TLS with openssl), it looks like there might be an active firewall in place.

The connection on that port works with nc on both sides (nc -l -p 8883 on the server, nc server.com 8883 on the client)
It even works if I manually send the binary preamble for making a TLS connection, but leave off the last byte (again, captured with nc -l -p 8883 | xxd).  I think I see a delay...
Just incase I also checked if the connection is just being forced closed at 289 bytes, so I sent a lot of random text and it went through fine.
Sending the full TLS preamble results in nothing received at the server, and the connection closed.  I tried adding some delay before the last byte, it goes through and the connection stays open!

What the heck is this and how do I phrase my request to the company IT to allow it? (we have a special APN set up with AT&T and I think that's where it is)

Trouble shooting details:

I used nc -l -p 8883 to capture the TLS preamble from a successful connection attempt to the server from elsewhere (289 bytes)

0000000: 1603 0101 1c01 0001 1803 03f4 f363 0180
0000010: 3ce4 957f ee17 8b7f d8ef 9ce0 e608 1cac
0000020: d328 798d 8b10 cc7b b521 0....
...
0000120: 01

Then here's the client command to reproduce it:

(head TLS1.hex -n18 | xxd -r; sleep 0.3; echo 0: 01 | xxd -r )
                                  | nc server.com 8883 -q 1

< 0.3s, fails
= 0.3s fails intermittently
> 0.3s, succeeds

Shot in the dark, but maybe this is a firewall or other middlebox that can't handle ClientHello with length field >= 256 (and thus using both bytes of the encoding).

When OpenSSL 1.0.1 first implemented TLS1.2 (and 1.1) in 2012, resulting in ClientHello containing more ciphersuites and additional extensions and thus by default exceeding 256 for the first time, there was a slew of reports of breakage on servers that had not been coded correctly to handle this; I don't recall any similar problems with firewalls but it isn't impossible.

To test, try s_client with -no_tls1_2 (or more simply with -tls1 or -tls1_1 as you choose) to see what happens. You can add -debug to s_client to see exactly what is sent and received, and in particular the two bytes starting at offset 3 in each record are the (big-endian) length of the content of that record: in your example this is 011c and the 5 bytes record header plus 0x011c bytes of content matches your total 0x0121 bytes.


Install my own proxy My school network has blocked a lot of webpages, including TeamViewer, which I need. The IT department told me to find a proxy, because it was their ISP who had blocked the sites. To connect to the internet all the school computers are set up like this: http://screencast.com/t/AQehWSxRk2N (I have scrolled the URL to the right.)

I have tried http://www.hidemyass.com/ and TORProject and everything, but they don't work. (They do work at home though.)

Do anyone know how to work this out. Maybe to set up my own proxy-server on my computer at home? I tried to find out how to do this once, but I didn't seem to find an easy solution as to how to make a proxy-server. (preferably with a password.)

Thanks! :D

Assuming your home computer is internet-reachable, the easiest thing to do is run an SSH server on your home computer. Then connect to it from your school computer via:

ssh -D 8080 user@home

Then you can set SOCKS proxy of your browser at school to use localhost:8080 and everything will be proxied through the SSH tunnel to home.

There are some issues you'll have to work out:

make sure the port you're going to use isn't firewalled at your school
make sure your home sshd is set up as securely as possible (no root login allowed, disallow password logins, etc)
unless you have a static IP at home, the home computer will need to integrate with a dynamic DNS service so that you know how to reach it


ARP spoofing with Scapy. How does Scapy reroute traffic? Background:

I understand that in order to ARP spoof a victim in a network using Scapy, we need to send ARP reply packets to the victim and the gateway router with the correct destination and Source IP address, but with the attacker's source Mac Address, essentially stating that the attacker is the gateway to the victim, and the victim to the gateway, hence being the man in the middle. Also the attacker would need to echo 1 to /proc/sys/net/ipv4/ip_forward to enable ip forwarding

Question:

So my question is, after arp poisoning the victim and the gateway, how will the victim's traffic be redirected to the router, and router's response traffic to be redirected back to the victim? Will the attacker need to change up the firewall configurations in iptable? Such as in the pre-routing chain of the nat table, redirecting victim's traffic tcp port 80, and 443 to the gateway IP, and also forwarding the router response packets (src port 80/443) back to the victim?

Since most of the examples on the web does not talk about their firewall configurations, so I was wondering if changing up the nat table for pre-routing chain was also a necessary step to take in order to administer a MITM attack.

Example:

https://www.youtube.com/watch?v=fkYd8MPzgts
Question about this example video: How in the world did the attacker sniffed the dns packet using scapy just by filtering tcp port 80. Since in the video the attacker did not show any firewall (iptables) configurations, I assumed that all of the victim's traffic including DNS query packets were all sent to the attacker, then how did the victim obtain connection with google and twitter if the attacker didn't forward the traffic to the gateway/victim?

Can someone please explain? Thank you in advance.

Scapy does not route the traffic, nor does it touch the traffic at all in this scenario. When you enable IP forwarding on a host, it becomes a router. When the host receives a packet not destined for one of its own addresses, its kernel will route the packet per its routing table. Since the traffic from the victim has a destination IP address not matching the attacker's machine, in most cases this will result in the traffic being forwarded on to the attacker's default gateway, which is typically the network's gateway/router.
For example, an attacker has performed a bidirectonal ARP poisoning attack. The victim thinks that the attacker's machine is the router, and the router thinks the attacker's machine is the victim's. The victim sends a packet to 8.8.8.8, which is received at the attacker's machine. The packet is not addressed to the attacker, so it is sent on to the default gateway. The response from the server behaves the same way; the router will send the packet addressed to the victim, which will go to the attacker. Again, it is not addressed to the attacker, so it is forwarded again.
You mention firewall rules being involved. A clean iptables/nftables setup has default ACCEPT for all chains. There is nothing inhibiting the above routing of packets once forwarding is turned on in the kernel, unless firewall rules have been added to prevent it.


Is it possible to have stateless server nonces in HTTP Digest When implementing a HTTP Digest server, there's the issue of nonces.

Server nonces (as opposed to client nonces)

must be issued by the server
may be re-used by clients as long as the server allows it
knows nothing about what user will use the nonce later

A naïve implementation is to remember all issued nonces in memory, but this introduces state: Either a client needs to talk to the same server, or the servers need to share the list of valid nonces, which becomes a scalability issue.

My question is: Is it possible to provide secure and stateless nonces?  I believe so, and would like it to be (in)validated:

Make the nonce a cryptographically signed message from the server:

an expiry timestamp (e.g. 86400 seconds in the future)
an a random number (maybe?)
a cryptographic signature (sha or hmac perhaps?)

This could all be bundled together in the nonce which is provided in the 401 Www-Authenticate header.  When any server sees this, they can verify the message integrity (by recalculating the signature). Then the timestamp can be checked, and if so then the nonce is good.

Is this technique described elsewhere?
Does this way of providing nonces defeat the purpose of nonces?
Is there any other way of providing stateless HTTP Digest authentication?

If the server is stateless, whatever the clients sends to "get authenticated" can be replayed. An attacker only has to eavesdrop on a request by a client, and then can send his own request with the relevant header simply copied. An expiry date prevents the attacker from doing that indefinitely, but even if the attacker can wreck havoc within your server only during one day, this is still unsatisfactory. Possibility of replay attacks is consubstantial to statelessness; it is unavoidable.

And HTTP Digest is not a great protocol anyway. HTTP Digest ensures a security service only in a model where attackers can potentially spy on exchanged data, but not alter it; this is not a very realistic model. In practice, you need something more thorough, like SSL, at which point you can send the password as is (HTTP Basic) and forget about HTTP Digest.


Acquiring remote forensic image from EC2 instance I'm trying to figure the best way to acquire remote image from an EC2 instance.

Here is how I took/trying to take an image of an EC2 EBS drive:

Using EnCase Remote Recovery (trial for 14 days):
1.a: on Windows, I connected via Remote Desktop, copied the servlet and started it (it basically to allow the client on local machine to connect). Now I can use the client on my local machine to explore and acquire an image of the EC2 instance. This one worked.
1.b: on Linux, I tried the same thing. However, the servlet is not working for some reason.
FTK Lite (this version does not require installation):
2.a on Windows, I connected via Remote Desktop while sharing one of my local disks where FTK Lite resides. On the remote machine I navigate to my local disk, run FTK Lite and start the acquisition. Since I'm sharing my local disk I can instruct FTK Lite to store the image on it. However, around 10% FTK Lite stops sending any data. I don't know if it's a problem with FTK itself or Remote Desktop.
2.b: I don't know how to do the same thing on Linux.
I'll try the snapshot feature of EC2.

What do you think about these methods?
How can I use FTK lite in Linux instance (I need the image to be stored on a different instance or my local machine).
Do you know any other method to acquire an image from an EC2 instance?

Thank you.

An EC2 system is relying up on Elastic Block Storage (EBS).  Then you can take an EBS snapshot of the system, and download this image.

You now have a full disk image locally, and you could run the instance it within a VM,  or whatever.


Securely storing bank account details in database I am developing a service that will involve the direct debit of customers' accounts on a routine (weekly, monthly, etc.) basis, and so I'll need to store their information (BSB/routing number and account number) in my database. I am very concerned about security, and so my first thought was to not store this information, but after reading through many other questions about this topic, I have come up with a solution that I think will work - but I would like to run it past you guys to make sure I haven't left open any security holes.

When a user registers to the service, it will create a public/private key pair with the private key having a passphrase that the user provides (their account password). The password is hashed with bcrypt, and the public and private keys are stored alongside the password hash in the user table.

I will also establish a single admin public/private key pair which will be used when we need to process a direct debit. The public key will be known to the application and database, but the private key will be kept off of the server, so that the data can only be downloaded when encrypted, and then processed elsewhere. An alternative to downloading when encrypted would be to instead upload the private key to the application, decrypt the data for that request only, and then delete the uploaded private key - is this a security hole?

When a user registers for direct debit, the service will take the user's public key, and the admin's public key, and encrypt them using GPG's multiple recipients feature.

To the best of my knowledge this covers the following situations:

If the user wants to view the data, they will need to provide their password to decrypt the information.
If the user wants to add more data, they won't need to provide their password as I just use their public key.
If the admin wants to view the data, they will need to download the information and decrypt it, or else upload their private key (see above).
If the user changes their password, I will just need to update their private key. If they have forgotten their password, the only way I could decrypt their data would be through the admin private key, but as this is kept off-site the data should be deleted.

Will there be any concerns if the admin key pair ever becomes compromised (apart from the obvious) and I needed to generate a new admin key pair and then re-encrypt all of the stored data?

Are there any security holes in this design? I am admittedly no expert but I've tried to do my best with researching this, and would now love to get some input.

I have also looked in to services like Authorize.net's Customer Information Manager (CIM) but as far as I can see you need to be using their service to collect payments, when instead we have already established our own merchant to do this at a cheaper rate, and so we just need a secure information storage service.

The service will be using HTTPS, and running on Ubuntu 12.04, with PHP and MySQL, if that helps.

Any advice you can give will be greatly appreciated!

Thanks

The password is hashed with bcrypt, and the public and private keys
  are stored alongside the password hash in the user table.

Storing the private key means a compromise of the database would allow attacker to decrypt the bank information.  You might as well store the bank information in plain text.

Why exactly would the bank information need to be encrypted by the user's key anyways?  Is the user going to request that information "please tell me the bank account I told you about earlier"?


How should I secure a contact form that appears on every page of a website? My client has a small "Contact Us" form on every page of their website. They are adamant about not including CAPTCHA verification on these forms, to keep them easy to use, but I feel it is my responsibility to implement some type of security against brute force attacks, etc. What are my options here, especially those that involve no changes to the UI of the forms.

FYI, the client has ColdFusion 8 as their server-side scripting language, which is currently used to insert the data into the database. The solution doesn't have to be specific to ColdFusion, though. I'm looking for ideas here - not necessarily code snippets.

This is a good summary article on CATPCHA:

http://www.smashingmagazine.com/2011/03/04/in-search-of-the-perfect-captcha/

I think you are right not to use CAPTCHA. Research has show that CAPTCHA can lower your conversion rates by 3% and potentially up to 30%. Even employing someone to manually filter or using mechanical turk, yourmaninindia.com etc maybe cheaper and better for your customer experience

Good passive measures:

The Roboo script. Demoed at Blackhat this year and gives you some DOS protection as well.
Adding a honeypot hidden field that should never be completed. You can use Javascript to fill this in automatically on legitimate form submissions and validate server side.
Velocity measures such as how fast the form is submitted.

All these are not perfect, can cause problems for disabled people and can give you false positives. If you are still getting an unacceptable amount of spam or robot usage then use the most popular and free option Re-Captcha. Ideally combine this with the passive steps above to only present the CAPTCHA if you suspect a bot submission (i.e. an adaptive approach not presented every time to users). Yes Re-Captcha has been broken in research labs with as much success as 25% using OCR techniques but it is still enough to deter dragnet bots seeking unprotected targets (running faster than the guy running from the bear). Also you are helping Google translate the worlds books and until duolingo.com comes up with its next innovation that is not a bad thing.


Malware removal: Iframe injected javascript My Joomla! website is infected by an iframe injected malware, according to Sucuri SiteCheck:

To remove the malware, does it suffice to remove the infected file site/media/system/js/caption.js? Or should I, and how to, further investigate the all the other files?

Thank you in advance for your help.

Update:

First of all, many thanks to @begueradj, @Aurora, @André Daniel and @SilverlightFox for their comments and answers. And please forgive me for not replying earlier, I have been involved in another urgent mission and have just finished.

I was so panic that I deleted the infected file, i.e., .../media/system/js/caption.js, and took the site offline. Now what I am planning to do are:

On localhost: upgrade Joomla! as well as all the installed extensions to the latest versions.
Move the website to a new hosting.

Does it suffice?
Since I deleted the infected javascript file, I do not know what the injected code look like, thus will not be able to find other infected files.

It is more likely the attacker has succeeded to install a backdoor. It is by nature hidden, and quite hard to detect and disable.

You need to check some important and classic directories such as the one you use to upload images or other files because you usually trust such directories and never check what is inside them. Also, if your Joomla website has inactivate themes, it is better to delete them because they are targetted by hackers to incubate their backdoors, usually.  Also, you will need to check the source code of your most sensible files (such as configuration files). At the end you will need to change your credentials and ask the users of your website to do the same, but also the credentials you are using to access your server.


What is the difference between YARA and CLAMAV? Can any one explain the difference between YARA and ClamAV ? Are they just two different ways of writing AV or Malware signatures ?

Yara is a tool which is used to write a rule for detection of malwares whereas CLAMAV is antivirus that has predefined rulesets that is used to detect the malicious software or malware. Today there are various antivirus engines use yara rules to detect malwares. YARA provides simple and efficient way of writing rules. It is more popular because of it can be used through yara-python library. So if you want build your own malware detection framework so you can use it efficiently.


I want to host a server from my home computer; safe? I am planning to make public a website I have been working on; it seems to me that (in my very limited experience) the only way I can do this without needing to pay any extra money to external hosts etc. is by hosting the server from my computer at home.

Of course, I am extremely scared of doing this; in the design on my site I have followed every security guideline I know of, but I'm scared attackers will still be able to get at other devices on my local network or access to my own personal computer (from which I intend to host the server.)

I've noticed though that my ip is already exposed to the internet: if I visit my public IP address in the browser, my home router's page pops up, which also worries me – EDIT: actually this only happens for devices already connected to my local network, a remote device seems to be unable to access my router's configuration page this way.

I have run nmap on my public ip, without my server running, as I'd imagine it would be one of the first steps an attacker would take:

Nmap scan report for ***********************
Host is up (0.0023s latency).
Not shown: 995 closed ports
PORT     STATE SERVICE
53/tcp   open  domain
80/tcp   open  http
443/tcp  open  https
5000/tcp open  upnp
8080/tcp open  http-proxy

Nmap done: 1 IP address (1 host up) scanned in 40.89 seconds

Are any of these services vulnerable? They are all managed by my router, and I haven't set any of them up.

Here are the nmap results from an external source:

Starting Nmap 6.00 ( http://nmap.org ) at 2016-08-26 15:44 EEST
NSE: Loaded 17 scripts for scanning.
Initiating Ping Scan at 15:44
Scanning **************** [4 ports]
Completed Ping Scan at 15:44, 0.06s elapsed (1 total hosts)
Initiating SYN Stealth Scan at 15:44
Scanning **************** [100 ports]
Completed SYN Stealth Scan at 15:44, 4.25s elapsed (100 total ports)
Initiating Service scan at 15:44
Initiating OS detection (try #1) against ****************
Retrying OS detection (try #2) against ****************
Initiating Traceroute at 15:44
Completed Traceroute at 15:44, 0.04s elapsed
NSE: Script scanning ****************.

[+] Nmap scan report for ****************
Host is up (0.033s latency).
All 100 scanned ports on **************** are filtered

Too many fingerprints match this host to give specific OS details
Network Distance: 9 hops

Basically, I'd like to know what steps I should take to best reduce the chances of an attacker gaining access to my personal computer or other devices on my home network, and if this is indeed an absolutely terrible idea I'd love pointers in a better direction.

Of course, I am extremely scared of doing this; in the design on my site I have followed every security guideline I know of, but I'm scared attackers will still be able to get at other devices on my local network or access to my own personal computer (from which I intend to host the server.)

Well...

  in the design on my site I have followed every security guideline I know of,

These guidelines don't mention anything about not having public-facing assets on the same network segment as resources you're concerned about? If you were a shopkeep would you leave your money just sitting in a pile on the same counter you serve customers from?

Personally I'm a strong proponent of not hosting web services from your home connection. Several reasons:

99% chance you are violating the terms of your agreement with your ISP.
If you get compromised and your computer is used to serve spam, your ISP may cut off your internet access altogether.
If you get compromised and your computer is used to serve Very Bad Things, you're going to have FBI agents serving search warrants to your home and confiscating all your personal gear.
You violate what little security and privacy you have on your home LAN by opening up an exploitable public-facing entrypoint.

All of these things could be avoided with a $5/10-a-month webhost.

No EULA violations for hosting a web site (that's what you're paying for!).
At worst your host sends you an angry letter and stops hosting your site.
The FBI confiscates your host's equipment instead of yours.
You get more peace of mind at home.

DigitalOcean is the cheapest I've seen at $5, you can get AWS down to $6-7 a month with a fixed contract, or most other hosts charge $10. Scrape together a wad of cash and buy a disposable credit card if you must.

As a result of not being a cheapskate you will avoid a world of problems.


SSL certificate: would this self-signed cert alternative be secure? This article got me thinking: would the following alternative (using self-signed certs and a third party service) be less secure than the current CA hierarchy trusted by browsers? I quote:

  The really depressing part is that it would be trivial to set up a
  simple service where users could upload their domain certificates to a
  site (after proving ownership of the domain by placing a file in the
  domain web root), and browsers could automatically check for the files
  there as a safeguard against this attack vector. The files are
  typically ~1KiB in size per domain.

This basically would prove that the certificate received from the website W was really made by the owner of W's (sub)domain, and that the visitor is not being victim to a MITM attack. Of course, this looks like a CA's job, but as CAs either can't restrain themselves from demanding absurd amounts of money (yearly or monthly) for such a simple service, or can (e.g. CACert) but won't be accepted by browser vendors in their lists of trusted CAs, an alternative should be found...

This trusted service could be handled by a not for profit foundation backed by the main browser vendors, and would really democratise the access to strong encryption and web browsing safety.

Is there a security flaw in this simple scheme? or are the browser vendors too interested in the CA cash machines?...

Here is what I think.

Imagine a rogue attacker uploading certificate for google.com to this central website. Now, on poisoning DNS records, it can redirect clients to a rogue server and capture all encrypted transactions. This attack would fail with the current scheme because the certificate presented by the rogue server (as google.com) would not match that in the trusted store.


Shell not always escalating privileges in narnia I'm going through the various overthewire wargames and I have a question about narnia0. The code in c contains

if(val==0xdeadbeef)
system("/bin/sh");
else {
printf("WAY OFF!!!!\n");

I got it to work with the simple buffer overflow, but I wanted to try using gdb to find other ways to exploit it. I disassembled main, then set a breakpoint after cmpl and before jne. Then I changed the machine code from 0x75 to 0x74. When I continued, it ran

system("/bin/sh");

but when I ran id I was still only in the narnia0 user group, whereas if I did the buffer overflow I was in the narnia1 group. Is it impossible to escalate privilege as gdb, and is there any work-around to escalate privilege in an environment where you can change the machine code/variables?

Looks like this is due to the program running under the currently logged in user's account (narnia0) when you run it with gdb vs. the program running under the narnia1 user account when the program is executed.

This can be investigated further by looking at the permissions on the program file.   (Use 'ls -al' to check out the file's permissions.

Look here for how the file permissions work: https://en.m.wikipedia.org/wiki/Setuid


How secure is JavaScript based OAuth 2.0 JavaScript based OAuth exposes the client ID of the application and it trusts only on the domain requesting the access token. The domain name can be forged with a DNS hijack (or a virus affecting /etc/hosts). Then why is JavaScript based OAuth supported by Google, Facebook for clients not using HTTPS? Or am I missing something?

OAuth 2.0 pretty much requires HTTPS, as it doesn't have any means to make tokens secure. So, if google and facebook actually allow you to use OAuth2 over plain HTTP that is bad. Are you sure that is the case? I thought both of them are https-only for quite some time.

On the other hand, OAuth1 works fine over plain HTTP as it has it's own layer of secure digital signatures


Is there a Skype plugin that uses TLS and ZRTP I'm curious, if one can upgrade the security Skype offers to avoid a man in the middle snooping in on the calls by both parties using a client side plugin? Does one exist for this purpose?

A bit of background reading:

The Daily Dot: New FBI surveillance unit focuses on Skype and wireless communications
RandomBit.net: Skype backdoor confirmation
Neowin.net: FBI: Monitoring Skype and Gmail are "top priority" in 2013

No, there isn't any plugin for Skype that would plug into its transport layer and custom encrypt calls peer-to-peer, and there likely won't be any as:

  Skype uses a closed proprietary protocol, which they do not publish. Skype intentionally does not interoperate with the rest of the VoIP industry, which is built on open standards. [1]

Skype is now fighting back to regain its reputation and end users' trust, after the series of news stories, such as you link to, have alleged that: Skype changed its network's architecture since its acquisition by Microsoft last year to enable “lawful interception” of calls.

  Mark Gillett, Skype COO:  "Skype to Skype calls do not flow through our
  data centres and the "supernodes" are not involved in passing media
  (audio or video) between Skype clients.   These calls continue to be
  established directly between participating Skype nodes (clients). In
  some cases, Skype has added servers to assist in the establishment,
  management or maintenance of calls."

Well, right. Managed calls anyone?!

TL;DR - Since Skype is using a proprietary hybrid TLS (combining both client-server and peer-to-peer encryption protocols, and not that safe ones at that either), I don't see them opening up to the wider VoIP community and supporting custom encryption schemes and ZRTP.


Encrypted offsite storage using sshfs and cryptsetup/dm-crypt/LUKS I'm interested in an encrypted offsite storage scheme, but I don't want to depend on the vendor for encryption.  I have an idea for doing so by combining sshfs with cryptsetup/dm-crypt/LUKS, but I'd like to know if there are any obvious problems with this scheme.  Essentially,

Use sshfs to mount a remote drive
Create a random encrypted volume via head -c 10MB /dev/urandom > volume
Make a LUKS container with cryptsetup -y luksFormat ./volume
Open the encrypted volume with cryptsetup luksOpen ./volume myvol
Format the volume via mkfs.ext4 /dev/mapper/myvol
Mount the encrypted volume mount /dev/mapper/myvol /mnt
When done, unmount the encrypted volume, close it, and unmount the remote drive

After everything is setup, I'd just use steps 1, 4, 6, 7.  Anyway, again, I'm just interested in some kind of offsite encrypted storage scheme where I don't have to worry if my host is snooping or not.  I'm interested if there are some possible issues with the scheme that I described above using sshfs combined with cryptsetup/dm-crypt/LUKS.

For dealing with remote drives, you're probably better off using a file-level encryption system like eCryptFS.  Alternatively, if you're just looking to store backups or something similar, you can use the built-in encryption in tools like duplicity (that uses GnuPG for encryption).

Using LUKS like you've described should be fine, and is essentially creating an encrypted container, but you'll probably have suboptimal performance and it'll be more difficult if you ever want to encrypt more data than you've prepared the container for.


Will signing messages with key derived from password work better than sending password I was wondering recently how to create secure mechanism for sending password while log in to the system. Then i had wicked thought why to send password at all.

Let's imagine mechanism where client sends user id who wants to be logged in, server "welcomes with bread and salt" by sending challenge and random salt.

Client calculate hash of concatenated salt and password, and then uses it as shared secret to calculate HMAC of challenge, and sends it back to server.

In this case login details are never shared across the network, and login message cannot be replayed.

But are they any downside of this which i didn't thought about? And why it's bad idea (I'm assuming is bad, as nobody is doing in this way)

You should transfer the password over HTTPS. For storage, hash the password with Argon2.

Do not attempt to roll your own scheme. Anything beyond the above is generally unnecessary except for specific circumstances (e.g. where you need the server to have no knowledge of the password, in which case you want SRP).


Is it safe to assume that a JWT is valid if the library says so? This is my first time using JWT. I'm using the jwcrypto library as directed, and the key I'm using is an RSA key I generated with OpenSSL.

My initial inclination was to store the JWT in the database with the user's row, and then validate the token's claims against the database on every request.

But then it occurred to me that the token payload is signed with my server's private key.

Assuming my private key is never compromised, is it safe to assume that all data contained in the JWT, presented as a Bearer token by the user, is tamper-proof? I understand that it is potentially readable by third parties, since I'm not encrypting.

What I want to know is, is there anything I need to do to validate the user's JWT besides decrypt it and let the library tell me if there's anything wrong?

The way to verify a JWT is to check it's algorithm, signature, expiry and issuer. Other claims can be checked too.

Signature

For RS256, the auth server will calculate a SHA256 hash of the header and payload, and sign it with it's private key. To verify the signature, the relying party again calculates the hash of the header and payload, and checks that it matches the signature decrypted with the public key.

Since the header and payload aren't encrypted, they can be tampered with, but then it won't match the signature.

Algorithm

Two serious vulnerabilities are possible when the server does not check the "alg" field [1]. This is because some JWT libraries verify the signature automatically using the algorithm provided in the header.

Firstly, if a hacker sends a JWT with the alg equal to none, the signature won't be checked.

Secondly, some faulty library implementations store the symmetric secret key and asymmetric public key in the same variable. If you've stored an RSA public key expecting an asymmetric algorithm, and a hacker sends a JWT with a symmetric signing algorithm, your server will check if the JWT was signed with the public key. Since the hacker has access to the public key, they can easily create valid JWT signatures.

Payload Claims

JWT libraries will check the current time is between the issued time iat and expiry time exp. Instead of checking the exp, some people prefer to check the current time is less than the issued time plus the maximum acceptable JWT lifetime.

The issuer iss should match the expected issuer.

Sources

[1]: https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries
[2]: https://auth0.com/docs/tokens/guides/validate-jwts


Counterarguments against an anti phishing procedure Consider the procedure below. What are your counterarguments, related to both security and user experience?
This is a follow up on my previous question on the same topic.
Step one: An employee submits an e-mail to coworkers (non-internal roles are also covered):

Step two: The e-mail server intercepts all incoming mails and substitute hyperlinks to non whitelisted sites, e.g. surveymonkey.com/my-survey with redirect.contoso.com/surveymonkey.com/my-survey, and send known authors the following message:

Obviously, if the GUI of the e-mail client can be modified, the verification can happen as the mail is authored.
Step three: If the author takes no action, the recipients get the e-mail after three minutes, but are presented with this message when they click the (doctored) link:

Over time, the user-vetted whitelist could be augmented with white- and blacklists provided by the security part of the organization.
The assumption is that this would intercept most link-based phishing attacks with a message of caution, while also keeping employees alert, due to the two factor authentication involved, without significantly degrading the user experience or imposing excessive policing of the employees.
So again, what are your counterarguments, related to both security and user experience?

As pointed by schroeder, there are many moving parts here, thus many instances where same arguments can be positive or negative.
Here's my argument for one case.
Let the case be: employees of this org share pretty often links via email. Consequently, employees often click and visit links from emails.
From the sender's point of view: after several such messages the sender can likely develop a pattern whether it is better (faster) for her to let it be or "confirm authenticity". In the best case she can "confirm authenticity" every time using a mental shortcut if this is possible. That is, a no-brainer to make her request acceptable asap. Let's suppose she has to "confirm authenticity" by filling a one-line form with her judgement of authenticity. Having worked in a SOC and completing many tickets, my colleagues and I developed standard "fillings" to copy-paste without thinking, because thinking is expensive.
This sender scenario looks okay from a security POV and okay-ish from a usability POV to me.
The worst case sender scenario is that she will ignore the confirmation and let the email be sent with the warning message.
This sender scenario looks the same from the security POV and little worse from the usability POV (receiving bot emails).
Let's look at the receivers' scenario.
Receivers are used to often click and visit shared links via email.
In the best case scenario, the links are vetted and authenticated.
This seems ok. However, a question arises on how they perceive this mechanism (if they know about it). Usually, the organizational infrastructure is perceived as secure, so they mainly feel safe on clicking links at work. If they know this mechanism is in place, this may reinforce this perception. This is not great if they whole system will not work in the end. But it is neutral in case it works IMO.
In the worst case receiver scenario, all (many) links were flagged as potentially dangerous causing the warning to be displayed all (many) times. This is bad.
It is bad, because the habituation to repeated and ill-perceived warnings is notoriously a big problem in human computer interaction and still not solved, as reviewed here,here. This means that the receivers are likely to get used to ignore the message, they may literally become blind to it (cognitively speaking). Thus invalidating the whole system. This is bad from both security and usability POVs.
So, we have covered the extremes of one possible case: the case of the org with lots of link sharing.
The positive extreme is where senders always "confirm authenticity" and receivers do not perceive an "improved security". There is some burden on the sender's side from the usability point of view. No burden for receivers, though. On the security side, external/untrusted links are going to be flagged. Depending on the ratio of # of rusted/un-trusted shared links, e.g. trusted >> un-trusted, this may result in a positive outcome for security.
The negative extreme is where senders never "confirm authenticity" and receivers (almost certainly) will ignore the warning message. It follows that the same "security level" is kept, but usability is worsen on both sender and (even more) receiver.
Of course there is a continuum between the extremes, and if that continuum is measurable (e.g. how many trusted/un-trusted links are sent in time), chances are that a data-driven decision can be made. If not, maybe a testing period with control groups may be relevant to measure that.


How are "security levels" of identities in TeamSpeak 3 implemented? TeamSpeak 3 VoIP communication system uses a concept of so called identities to identify the client to the server. These identities are basically public/private key pairs.

In order to prevent people from just generating a new identity after being, e.g., banned, they added a feature called security levels. Increasing security levels take exponentially more CPU time to reach.

This way a banned user needs to spend at least a minimum amount of time to generate a new identity with the required security level before he is able to join the server again.

Now to my question:

How are security levels implemented, so that the time to improve one can increase exponentially but the time to verify one at the server-side stays the same (or at least increases just linear)?

A TeamSpeak identity is simply an ECC key pair for the NIST curve ECC-256 as generated by the libtomcrypt library, together with a counter value that is a 64-bit unsigned integer.

The security level makes use of a classical Proof-of-work system.

Let PUBLICKEY be the base64-encoded string of the identity's ASN.1 DER encoded public key. Further, let COUNTER be the decimal ASCII-encoding of a 64-bit unsigned integer. Then the security level is defined as follows.

securitylevel := leadingzerobits(sha1(PUBLICKEY || COUNTER))

Consequently, the expected number of counter values that need to be tried to reach security level n is 2^n (under the assumption that SHA-1 is a uniform random function).

Note that in theory, the maximum security level could be 160 (as SHA-1 produces a 160-bit hash). However, the TeamSpeak client seems to set the limit artificially to 128. In practice, this makes no difference, as no one will ever reach a security level over 128 (except another breakthrough in attacking SHA-1 happens).

Source: TSIdentityTool, which is an open source implementation of the identity and security level mechanisms.


What is the optimal result for the elliptic curve patent issue? I saw an article this morning, discussing the fact that RSA and DH may be significantly less secure in the upcoming five years.  Although the chance that this will materialize is small, I immediately turned to thinking about reasons why ECC isn't mainstream.  The biggest obstacle I have been able to come up with is the fact that BlackBerry (Certicom), and some other companies own a ton of ECC patents, and mostly "own" the technology.

What would be the optimal solution for this issue?  I am aware that there are numerous public licenses for open source (FOSS, FLOSS, etc.), but, having never used them before, I am not familiar with their applicability (if at all) in this situation, nor am I familiar with the way that these patents could become open to the public aside from time and purchase.

Who would have the finances and motivations to actually purchase these patents?  Are there corporations or organizations that do this in order to bring technology into the open source community, or are there just some rich individuals who do this ad-hoc?  Is there another, more optimal solution which could occur, such as white house intervention?

ECC patents are more about implementation techniques than the actual mathematical objects. Using elliptic curves for cryptography has been theorized and published in 1985, and patents live for only 20 years, so using elliptic curves is, per se, patent-free since 2005 (whether such patents would have held in court is unclear, but now these do not apply anymore).

It has been said that the implementation of ECC in OpenSSL has been contributed by Sun Microsystems who took great care, in that time, not to use any implementation technique covered by any patent. In that sense, using OpenSSL will keep you free of the shark-infested patent waters. Note that nobody (and certainly not me) is guaranteeing that there won't be any patent-related legal trouble if you use OpenSSL (there are people who sue other people for a living, whether their case is valid or not), but this seems improbable. About half the Web today is powered by Apache+OpenSSL, and ECDHE support (hence elliptic curves) is enabled by default. If there was profit to make by suing people who use OpenSSL, the environment is so target-rich that the trial-feast would have already begun for good -- and that is not happening.

ECC patents which might still be applicable are mostly about some optimizations of implementation of computations over curves in binary fields, in particular Koblitz curves and normal bases. See this previous answer. You will not use that without knowing it, though.

Stating that Certicom and other companies "own" the technology is, at best, debatable. These companies occasionally claim ownership. However, whether mathematical objects can be "owned" at all is unclear. And the 20-year patent clock ticks for everybody; anything which was published in 1993 or before is now, by construction, patent-free.


How does attacker Brute force facebook account if there is a limit for tries? I am wondering how does a user use Kali with python Brute Force Algorithm to  brute force accounts like a facebook account when there are security measure in place like:Pause your try after 3 unsuccessful login?

Edit: https://www.youtube.com/watch?v=bsh9_se3UC0

In the above video, the user used Kali and ran a python script that ran a "dictionlist".txt against a specific fb account, so i am wondering why it seemed that the account didnt block the attempt after 3 times?

They don't.

If an attacker is trying to get into a specific account, he will rely on phishing or malware.

If an attacker is just trying to get working accounts, he will have a wordlist of emails and passwords that he'll try, thereby bypassing the restriction of password attempts simply because it's not being attempted on the same account.


URLEncode vs HTMLEncode for XSS prevention I have one project (in Java) that the programmer used URLEncode to output content as part of HTML instead of HTMLEncode.

What is the risk that it is XSS vulnerable? (Let’s forget that it’s different encoding and he will get different results)

What is the right way to do HTMLEncode in Java?

Risk assessment. If the URLEncoded data is inserted into HTML context (e.g., between tags), I do not know of any way to introduce a XSS attack.  URLEncode will escape the <, >, and & characters (to %3C, %3E, and %26, respectively).  In modern browsers, I believe this is sufficient to prevent XSS for values inserted between tags.

There are some more obscure cases where attacks might be possible.  If you are introducing untrusted (but URLEncoded) data into other parse contexts, such as a URL (e.g., the HREF attribute of the A tag), into Javascript, or into CSS, then it is possible that XSS attacks may still be possible despite the use URLEncode.  Nonetheless, these contexts are less common, so I suspect they're not what you're talking about.

So, in short, this is unlikely to be vulnerable to XSS (as far as I can see).

Why you shouldn't do it. Nonetheless, as I think you recognize, URLEncode is clearly the wrong solution for this problem.  It escapes data in the wrong way, and will cause the data to be mangled when the user views it in their browser.  Don't use URLEncode; it is the wrong tool for the job.  Instead, use the proper escaping function for the HTML context that you are going to use.

How to do it properly.  See my discussion elsewhere about how to select the proper escaping function, and where to obtain an implementation of that escaping function.  For instance, OWASP ESAPI is a fine library full of HTML escaping functions that can be used to prevent XSS vulnerabilities.


How to detect credit cards harvested from memory? Had a chat recently with PCI compliance specialist and got to realize there is a way to steal raw data from Apache / Nginx memory e.g. credit cards. It's called "harvesting" and becomes pretty common.

Let's say somebody hacked in through a file upload functionality and gained access. What would be the way to detect it if he managed to harvest anything or is still harvesting, assuming he could clean up/change logs and mods after himself?

Once an attacker gains control of a computer, you cannot trust anything on that computer; inspecting the computer cannot tell you with certainty what happened or is happening.

Your best bet is to watch for the attacker's efforts to get data off of your network and onto a computer under his control.  Monitor outgoing connections at the firewall to see if there are any going to unusual locations; inspect outgoing data to see if it contains anything that looks like sensitive data.

You can also attempt to spot the attack by having the server send its log messages to a secure logging server and inspecting for things that look like an attack.  However, 1) there will be a lot of false positives, 2) a successful attack may not create a log entry, and 3) once the attack succeeds, further log entries cannot be trusted.  Don't expect this to be useful except possibly for post-incident analysis.


How do polymorphic/metamorphic/self-encrypting/self-changing file infectors know if they have infected a file or not? If a virus rewrites itself for each infection how would it know if it has infected a file or not? If it keeps infecting the same file soon the whole file structure will be corrupt. For example how does Simile or Sality know if it has infected a file or not?

EDIT: they can't check something simple like "if they append 'kkk' to the end of the file" otherwise AV's would check that and the whole purpose of being polymorphic/metamorphic etc. would be defeated.

Eric Filiol's paper Metamorphism, Formal Grammars and Undecidable Code Mutation pretty much shows that it can be made impossible for a virus to know if a metamorphosed copy of itself has infected a file.  Sic transit gloria anti-virus.


openssl s_server without PSK/certificate, but with client certificate validation Is it possible to use openSSL without encryption and without a certificate at the server, but with validation of the client certificate?
I'm not sure which cipher allows this (or where to get this info).
I tried the following:

server:

openssl s_server -cipher NULL-SHA256 -nocert -CAfile client_cert.pem -Verify 4 -verify_return_error  -accept 44330 -www

client:

openssl s_client -cipher NULL-SHA256 -cert client_cert.pem -key client_key.pem  -connect 10.10.1.87:44330

But I'm getting errors at the server and at the client:

server error:

4699434604:error:140270C1:SSL routines:ACCEPT_SR_CLNT_HELLO_C:no shared cipher:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.11.1/libressl-2.8/ssl/ssl_srvr.c:1115:
ACCEPT

client error:

CONNECTED(00000003)
4447727212:error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.11.1/libressl-2.8/ssl/ssl_pkt.c:1200:SSL alert number 40
4447727212:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.11.1/libressl-2.8/ssl/ssl_pkt.c:585:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Start Time: 1582732375
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

From RFC 5246 (TLS 1.2):

  A non-anonymous server can optionally request a certificate from
         the client, if appropriate for the selected cipher suite.

Thus, you need at least a cipher suite where the server is not anonymous, i.e. NULL as you've tried to use will not work.


Examples of software web clients (web browsers, IM clients, etc) written in "secure" / managed languages After reading this article ("Everything is broken" by Quinn Norton) I was about to ask a question similar to this one (Why are security-crucial software written in unsafe languages?)... but actually I am more interested in counter-examples — where the security-crucial software is written in safe languages and does not use any "unsafe" libraries (except, maybe, some OS libraries — it's very hard to do without them...). By safe I mean, at least, not prone to buffer overflow attacks and other "nice" gifts from C/C++.

I have found so far only one example — tkabber, which is written in Tcl, but it does use OpenSSL, which is written in C, which makes it inherently unsafe. And every web browser that I can think of is written in C or C++, too...

The short answer is

All software is built on top of lower level software. Java is built on top of a Java Virtual Machine which is built on top of an operation system which is built on top of device firmware and your motherboard BIOS.
All software has bugs.

You can't say, I use Java so I am immune to buffer overflow attacks. Computers don't work like that because not matter what programming language you use, everything eventually ends up as instructions that execute on your CPU. There will always be an interface between your "safe" language and your "unsafe" CPU instructions.


Who is responsible for the strength of user's passwords? Who is responsible for a user's password's strength?  Is it us (developers, architects, etc.) or the user?

As a web developer, I've frequently wondered whether I should enforce the minimal password strength on my websites/applications users.

I frequently meet regular people (not geeks or IT professionals) that hate it when they are required to mix lower and upper case letters, add numbers, not to mention other characters in their passwords.

I'd prefer to measure passwords strength and only inform the user about it rather than mandate it. This way, those who don't like adding numbers or mixing cases would be informed, yet allowed to use weak passwords.

I'd still put a minimum length requirement, but should I enforce further minimal requirements?

If a user, who has a very simple one word password, has his account hacked in a dictionary attack, is it his fault or is it our fault that we allowed for such a simple password?

You cannot answer this question without answering the following question

  If a user's password is compromised, does that only put that user/that user's data at risk, or does it also put other users at risk?

If the system does not compartmentalize accounts, then a user cannot keep their data safe by choosing appropriate credentials, so administrators must be responsible, in part, for the overall security of the community.

If the system does compartmentalize accounts, then a user can only harm themselves by choosing weak credentials, so shifting responsibility to the user can be appropriate.

For example, email mailboxes are well compartmentalized; compromising one account does not compromise others much.  Some accounts might be set up to not treat as spam mail from other accounts, but there are many other ways to impersonate email senders so the ability to send email as a user is not often a huge escalation of authority.  An administrator can abdicate responsibility for password strength without compromising the security of the system.

But file systems and source code repositories are not well compartmentalized. Compromising one account whose ~/bin directory is on other users' PATHs, or which has commit access to a vital source code repository can lead to the compromise of many other accounts and systems via trojans.  In this case, compromising one account escalates authority system-wide; administrators cannot abdicate responsibility for password strength because they cannot abdicate responsibility for system health.


Recover deleted file despite full disk encryption This might be a stupid question, but I'll go ahead and ask it anyway.

Say I am on Windows and I create a file, secret_financial_plan.txt, where I store all my company's black market financial operations. Once my operations are all finished, I delete the file and empty the recycle bin to cover my tracks.

A few days later I realize "permanently" deleted files in Windows are fairly easily recoverable. So, I decide to apply full disk encryption (FDE) on my device by switching over to Linux and using LUKS or by encrypting the drive in Windows with Veracrypt or by using some other piece of FDE-software. Would it be possible for a forensics expert, who does NOT have access to the decryption key, to recover the secret_financial_plan.txt file after having applied FDE, or not?

In addition to Moshe's answer, I'm going to provide an example with LUKS since some people seem unconvinced. Also, see here for why overwriting may not be 100% effective (although it certainly helps).

Example

Make a sparse file, create a filesystem, and mount it:

$ truncate -s 100G /tmp/device
$ mkfs.ext4 /tmp/device
$ sudo mount /tmp/device /mnt
$ sudo chown user:user -R /mnt

Make a few confidential files:

$ echo "super secret data" > /mnt/secret
$ echo "super secret data" > /mnt/confidential
$ echo "super secret data" > /mnt/top-secret

Get inodes for files:

$ ls -li /mnt
total 28
13 -rw-rw-r-- 1 user user    18 Nov 10 11:34 confidential
11 drwx------ 2 user user 16384 Nov 10 11:33 lost+found
12 -rw-rw-r-- 1 user user    18 Nov 10 11:34 secret
14 -rw-rw-r-- 1 user user    18 Nov 10 11:34 top-secret

Ensure files are written to disk, then get extents for inodes:

$ sync /mnt/*
$ debugfs -R "stat <12>" /tmp/device
...
EXTENTS:
(0):33793
$ debugfs -R "stat <13>" /tmp/device
...
EXTENTS:
(0):33794
$ debugfs -R "stat <14>" /tmp/device
...
EXTENTS:
(0):33795

Check those blocks to make sure the data is there:

$ dd if=/tmp/device bs=4096 skip=33793 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 1.9034e-05 s, 215 MB/s
$ dd if=/tmp/device bs=4096 skip=33794 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 1.888e-05 s, 217 MB/s
$ dd if=/tmp/device bs=4096 skip=33795 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 7.1178e-05 s, 57.5 MB/s

Remove the files:

$ rm /mnt/secret
$ rm /mnt/confidential
$ rm /mnt/top-secret
$ ls -l /mnt
total 16
drwx------ 2 user user 16384 Nov 12 17:34 lost+found

Format the device using LUKS, then create a new filesystem:

$ sudo umount /mnt
$ sudo cryptsetup luksFormat /tmp/device

WARNING!
========
This will overwrite data on /tmp/device irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase:
Verify passphrase:

$ sudo cryptsetup luksOpen /tmp/device encrypted_device
Enter passphrase for /tmp/device:

$ sudo mkfs.ext4 /dev/mapper/encrypted_device
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 26213888 4k blocks and 6553600 inodes
Filesystem UUID: 279e6c3b-a183-4a94-b06e-78db1665b2a0
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

Now we have a new filesystem:

$ sudo mount /dev/mapper/encrypted_device /mnt
$ sudo ls -lR /mnt
/mnt:
total 16
drwx------ 2 root root 16384 Nov 10 11:37 lost+found

/mnt/lost+found:
total 0

But is our secret data still there?

$ dd if=/tmp/device bs=4096 skip=33793 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 1.8944e-05 s, 216 MB/s
$ dd if=/tmp/device bs=4096 skip=33794 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 2.2056e-05 s, 186 MB/s
$ dd if=/tmp/device bs=4096 skip=33795 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 8.7082e-05 s, 47.0 MB/s

Conclusion

Unless you wipe the disk, it's probable that at least some of the old data remains there unencrypted.


Is it ok to use digital signatures as the mechanism for account verification emails? I'm implementing account verification (user registers, gets email, follows link to verify email address).

Many tutorials I see involve having a column in the users table for a random string, which gets generated before sending the verification email, and included in the query string of the verification link.

I'm thinking about using a public key to encrypt the email address, and attach the result to the query string instead. Then upon receiving a verification request, decrypt the query string parameter with private key, and check it against the email address. This way, there's no need for an extra column

I'm really shaky in my information security knowlege though. Is this a good idea? Would this work? Should I hash the address before encrypting it with the public key?

You're mentioning encrypting the email and digitally signing it. These are two different things which, although they both can be used in your case, have different practical outcome: by using encryption, you're hiding the encrypted data from view (the email address).

That being said, in theory, your scheme should work fine. In practice, however, i would shy away from such a scheme:

Most public key encryption (or digital signature) algorythm  generates big results: too big to comfortably fit in a query string. Or rather, it might fit in the maximum size allowed by most browsers but probably not in a single line of an email which will be inconvenient for your users.
Your scheme creates a single point of vulnerability: once the private key is compromised, all future transactions are tainted. If you use the regular "random key in a DB table" approach instead, you do not have this single point of failure: an attacker would need to compromised the existing DB to crack the system.
Your scheme is trading a trading a bit of DB space for a quite a lot of complexity in your code, increasing the attack surface and, potentially, leaving you vulnerable to a DOS (since public key validation is quite not exactly as cheap in CPU and memory as a DB lookup).

So, unless there is a real business case for it (for instance, if there is a strong need to be able to validate a query without reaching the database), I suggest you use the more common approach.

I'd like to add: generally speaking, I like to stick to the KISS principle with my software. Given two ways of achieving the same result, I try to stick to the one that requires the less code.


Securing a rest API with one client I am about to develop a REST API that will only have one "user" and I am curious about how I should implement security to make it as secure as possible(hopefully implementing some protocol that I am currently unaware of).

So initially I thought about implementing openID connect, however I believe that this won't be possible as the one user is an API that should be able to access my protected resources without user intervention.

I guess the question is: is there a standardized security protocol for these sort of cases, or does everyone just "go with the flow" and implement whatever works?

From personal experience it might be simpler to implement a keystone with a key that you only issue to the one user, vs. using the username/password authentication method, other than that I'm not sure what else you'd have to worry about. Maybe there is a way to combine both ways, but API's are usually set up so multiple clients can take advantage of the functionality, so a key might be the simplest way to restrict it to one single user.