Creating secure communication line for mobile payment Is SSL the most efficient way for creating a encrypted communication between the user's mobile to the backend server?

I understand that there is a flaw in SSL, so I was wondering is there other alternative that I can go for or should I keep the option of using SSL.

mobile payment in this case is like credit card payment (not with paypal just credit card)

SSL is probably not the most "efficient" way, but I'm not aware of any alternative that would be worth going to.

Mobile devices had WTLS to streamline the process for lower-bandwidth devices, but that's not a very viable system...  While you could roll your own, the rule of thumb (for crypto) is never roll your own.

Flaws have been found in SSL, and addressed; and they will be again.  However, your bank and your credit card company still use SSL, because it's the only widely supported method of providing reasonable security.

If the server in your case is hosted by your payment provider as @CodesInChaos suggests, they most likely only support SSL.  If you're planning on terminating the encrypted connection on your own server...  you should use SSL or expect massive hassles with your PCI (DSS and/or PA-DSS) certification.

In short... Just use SSL.


How to convert SSL Certificate for mobile app? I am in the current process of renewing my SSL cert for my website. I also have a mobile app for my site. I want to use the same cert from my website in my mobile app. How can I do this?

Thanks - I appreciate all feedback

Can you confirm what you're actually asking here;

Is it that you have two domain names IE;

1 - Networkguys001-website.co.uk

2 - Networkguys001-mobileapp.co.uk

and you want to have 1 certificate which secures both domains?

If this is the case then what type of certificate did you buy from Digicert, I've included a list below;

WildCard SSL Certificates,
UC (SAN) Certificate,
Extended Validation SSL,
SSL Plus Certificate.

Typically you'd could buy a wildcard which covers; *.Networkguy.com

1 - www.Networkguy.com <- Website

2 - Mobile.Networkguy.com <-URL for Mobile

However it depends how your current domains are structured and if they're hard coded and distributed already.

Anyhow if you answer the questions I'm sure a mobile


What measures should be taken when losing an iPad When losing a tablet that has been used to access email accounts , beside changing the passwords, is there anything more can be done?

What are the most common problems that might occur if the iPad was stolen, not just lost. Does iPad have anti-theft mechanisms to track the thief ?

There have been some other good answers here, but there are some other measures that can be useful too. In fact, not all of these are particularly technical.

As others have pointed out, adding a passcode to your iPad will allow for full system encryption, which prevents anyone from stealing data from the device. Combining this with auto-lock and auto-wipe provides a decent level of security against a thief. For the most part, your average thief is more interested in selling the iPad on for some cash, so they're likely to just do a factory reset and wipe it.

If your device has a SIM card, it works on the same principle as a mobile phone (cellphone), which means that a thief may be able to use the device on the network and charge payments to your billing account. The absolute best defence against this is to call your provider and have the SIM blocked.

They may also be able to register the IMEI number of the device on a blacklist, which works across all networks. This causes the device to display "IMEI Locked" and halt whenever it tries to join a network, regardless of which SIM card is used. Furthermore, most police forces will check IMEI numbers of any devices found during raids of criminals' houses against the database, in order to further indict the criminal for theft and recover property. In most countries it is an offence to change the IMEI number of the device in order to evade a block, and in the UK it carries a prison sentence. Whilst this won't get you your iPad back, it'll make it very difficult for the thief to sell it on.

The iCloud and "Find My iPad" apps are useful for simple location identification, but these are unlikely to be trusted by police as they can be inaccurate. For example, there was a case in 2011 where UK police kicked down someone's door in a search for a stolen iPhone, and it turned out that the location information was wrong - the phone was actually two houses down the road. This ended up with the home owner suing the police force for damages. It's just not safe for police to rely on that kind of data. However, it can be useful in contributing to the body of evidence, which is a technical term for an array of evidence that all points to a particular address or culprit.

On the flipside, remote wipe is an excellent feature. If the thief is sloppy when going about their work, they may end up powering the device on whilst it has an available internet connection (e.g. via WiFi or 3G) and the remote wipe will automatically kick in once the device phones home. This also provides evidence for police, because cell tower geolocation and traffic timestamps are cached.

Finally, there's insurance. If you purchased the iPad on contract, often your provider will have an insurance option that covers against theft. This will cost you a monthly fee (how much depends on your contract) but will usually result in a brand new iPad being sent to you if yours is stolen. Usually they ask for a police incident number as proof of theft, but other than that there's very little hassle involved. You can also use a 3rd party insurance company (Protect Your Bubble specialises in personal devices, but there are many other companies out there) to insure against theft. Typically these offer better cover, including accidental damage, water damage, etc.

But, of course, the best option is not to have it stolen in the first place! There are iPad lock cables available that allow you to physically tether your device to an object to make it difficult to steal, much like a Kensington lock that you'd use on a laptop. These only take a few seconds to set up and are ideal for situations like leaving your iPad in a hotel room. Combined with a passcode and auto-lock, this should be a reasonable deterrent to most thieves.


Are Free SSL/TLS Certificates Trustworthy ? Can Cert Providers Snoop On Traffic? I know nothing about encryption, SSL, TLS, certificates and have come across several companies offering free SSL/TLS certificates.

How trustworthy are these offers? Why would I want to adopt this change when I am not sure about if I can trust those offers?

More so, could the providers of such certificates snoop on the traffic that goes between the browser and the server, ultimately given authorities that either force the cert providers to do so (government legal action|NSA|etc.) or the providers themselves willingly doing so, a back door of some kind to tap into "secure" and "encrypted" traffic?

I find it hard to believe something that is given for free should increase the security of many many websites. More so I might even think this is some kind of con strategy so that governments|agencies|etc. can more easily snoop on traffic by either having some kind of master key copy or another technique unknown to myself that involves issuing "secure" certs while in fact they are not.

Forgive me my lack of knowledge in this field, perhaps I am mixing a few terms here, in any case I am having a hard time trusting this initiative. Am I simply too paranoid or have the bad news of the past increased my sensitivity towards this?

https://en.wikipedia.org/wiki/Comodo_Group#Controversies

https://en.wikipedia.org/wiki/Verisign#Controversies

Is there any technical security reason not to buy the cheapest SSL certificate you can find?

https://askubuntu.com/questions/497923/fake-usertrust-com-certificates-in-chrome

The SSL certificates used on web servers have two purposes:

They identify the web server, so that persons browsing to that site can be sure that they are not accessing the wrong site.
They encrypt the traffic, so that nobody can snoop on the traffic.

Identification
In order for any CA to be included in the common browsers (i.e. Firefox, Safari, Chrome, Internet Explorer, ...), the CA must follow the rules set forth by the CA/Browser Forum. This means that they must make some effort to make sure that a certificate identifying example.com does not get issued to anyone who isn't the owner of that domain. Different CAs do this in different ways. On the expensive side, in order to get an EV certificate from Verisign, you'd need to show actual proof of ownership of the domain as well as proof of your identity and your authority to request the certificate. This will include actual paperwork that gets inspected by humans - which is of course the reason for their certs being expensive. So a certificate issued in their Extended Validation program is about as reliable as is possible; you should be able to be certain that not only is the domain right but that the organization mentioned in the certificate is also verified.
On the free side, LetsEncrypt only need you to add a specific DNS record or HTTP resource to prove your ownership of the domain/web server. That way they have no idea of your actual identity, but they do know that the person making the request for a certificate is also in control of the domain. That is all the identification their certificates offer.
If you're not a company that needs to have the level of trust implied in an EV certificate, having a cheap or free certificate may be all you need. If you're a bank, or any big business, you probably want people to feel extra secure, and so you'll be willing to pay for the higher level of identification to get their company name next to the padlock in the browser window.
Encryption
TLS/SSL uses a public/private key pair. The CA that issues the certificate does so by signing the public key, aka the certificate. But they never see the private key - and it's the private key that is used to encrypt the traffic. This means that the CA has no way to snoop on the traffic.


How do VPN providers exactly encrypt traffic from client to their server? I'm thinking to build a VPN for personal use on a VPS but am unable to understand one thing. How exactly VPN providers encrypt data from client to their server? Suppose if I simply configure IP of my VPS and port in my browser it would be simple proxy it won't encrypt traffic that originates from my machine or browser.

If I use OpenVPN would it solve the purpose?

One more thing which I can't understand is, how do VPN providers exactly restricts usage to a few devices. Do they save device information? If by few devices they mean only X devices can run this VPN in parallel then how do the exactly restrict usage to only X devices because they have limited IPs and tons of users routing their traffic through them and there's no way to know to know who is using how many devices. If this is mapped to user account and they figure this out via his unique account then technically they are maintaining logs right?

How exactly VPN providers encrypt data from client to their server?

There's numerous algorithms, or cipher suites.  Which ones that can be used are dependent on the exact protocol used.  You want to avoid using broken ones so using the latest versions and good configurations of your software is needed.  One you want to avoid for sure is anything DES.
OpenVPN: You can look at any installed instance of OpenVPN's supported cipher suites as well.  The server must support the same suites as your client.  It's worthwhile to ask these questions and research for any VPN provider.  Older VPN mechanisms like Microsoft's PPTP had vulnerabilities and have been deprecated.

how do VPN providers exactly restricts usage to a few devices.

You sign into them with a username and password, or certificate.  OpenVPN supports user authentication and certificates.

there's no way to know to know who is using how many devices

There is when you authenticate to the VPN server.  If you're already signed in then it knows you signed in twice and can deny the session.

If this is mapped to user account and they figure this out via his unique account then technically they are maintaining logs right?

Not necessarily.  The VPN server maintains a list in RAM of who is connected.  It doesn't have to be written to disk.  Also, if the username/password or certificate is not tied to your identity in any way (e.g. if you paid cash and received the credentials on a computer/IP/device not tied to your identity) then there is no opportunity to track.
Revocation lists can be used to deny access to revoked certificates, and servers can be set to deny access to expired certificates.  Through this a mechanism of certificate issuance and delivery that is separate from identity can be implemented, though whether or not it is, only the implementer would know.


Vertical information portal security with a customized web browser I am creating a SaaS that will be delivered through a Vertical Information Portal (VIP).

In my research I have found that by developing a custom lean web browser and installing it on the clients platform, I can better restrict access to the portal on the web by only allowing this custom browser to access it.

I realize there is a threat of duplicating the the client browser. but I feel it is better option instead of any browser being able to access the portal to receive the payed services, and much easier to flag for piracy.

However, in regards to security of a custom browser, I have not been able to find any useful information. I would elaborate on this point, but unless I am missing something (which is probably the case), I have nothing to go on.

Can you point me in the right direction to make a thorough threat assessment on a custom browser build for a VIP delivered SaaS?

EDIT

By looking at the possibilities of a customized connection from server to client, I am not trying to re-invent the wheel, but looking at innovative options to make improvements to the wheel.

I do not make the assumption that any system is totally secure, and I fully believe the practice of IT Security is a constant work in progress that must be improved on (hence, the purpose of this question).

It sounds to me like you want your Web based SaaS application to be accessed only by browser/client/hosts that have some system integrity properties that are usually lacking in a typical web client host -- e.g. absence of malware, resistance to malware. If that is so, then you should consider developing a client that is a hardened dedicated browser appliance:
a) delivered to users as a liveCD image to be booted on typical PC HW from RO media;
b) built using SE Linux and bootstrap to restrict the executable application software to consist of a web browser;
c) local packet filter configured to permit communication only with the host(s) of the server side of the application;
d) browser configured to trust only the server certificate of the server side of your application;
e) several other supporting characteristics, but that's the gist.

An worked example of hardened dedicated browser appliance is available at:
    https://github.com/trustthevote/BrowserAppliance
In addition, you will probably want to build into the client image a key pair and PK certificate that the server requires as a pre-req for service. As you point out, it is certainly possible for the cert and key pair to be extracted and used by a different client host; but it is a strong measure to prevent casual or accidental use of "normal" client hosts such that the server would interact with these risky clients. If your application uses strong user authentication, then you de-scope your risk further by limiting the pool of people who would benefit from something as weird as cracking keys out of a perfectly usable hardened dedicated browser appliance, in order to rig up their existing PC as a client, without having to boot from RO media as a pre-req for using your application.

Hope this helps!
John Sebes
http://osdv.org


Hash that outputs a 8 characters I'm investigating a login system that exposes (probably) hashed passwords.

Password: HTSr0MF8Ou4liOCUayXHDg==

The password is stored in base64 format. When I decode it, I get random 8 chars regardless of password length.

The characters consist of random unicode characters. So, I know it's not an algo that I know like md5, sha, pbkdf etc.

Now, I don't want to crack it if it's a home brewed hashing algo, but if it's generic I want to find out what it is.

So, is there an algorithm known that

has 8 char fixed output
output consists of random unicode chars

When I decode it, I get random 8 chars regardless of password length.

With the given base64 of length 24 you get 16 bytes. These 16 bytes are 8 unicode characters only when interpreted as utf-16. When interpreted as utf-32 it would be 4 characters and when interpreted as utf-8 it would be a variable number of (possible invalid) characters.

But nothing in the base64 or in any context you provide indicates that it actually has to be interpreted as utf-16, i.e. this is probably only an (unfounded) assumption you make. It is more likely that these are just 128 bits without any specific structure, i.e. no unicode characters at all.

  So, is there an algorithm known that a) has 8 char fixed output b) output consists of random unicode chars?

Again, the question is more if there is an algorithm which creates 128 seemingly random bits. Sure, it's a random generator. And another famous algorithm which has a 128 bit output is actually the MD5 hash.


Self-signed certificates not working over Internet? My self-signed certificates are not working over Internet. What can be the problems?

Here are the setup details:

I have a Windows Virtual Machine in Azure with IIS, and a self-signed certificate for HTTPS. Things are working fine. Site is opening up without any issues.
NOTE: I have setup domain also, so that i can access this information over Internet.
When I try to access the HTTPS based website from my personal laptop, I get an error message: This connection is not trusted.

In case of above error in browser, I have to accept the setting to browse the site in non secured mode and only then I am able to access the data. But this is not what I want.

I want to access the data in secure mode only.

How is this possible using self-signed certificates?

Even if you see a message saying the connection is not trusted does not mean it is not an HTTPS connection.

In order to display or not such error messages, browsers try to validate certificates using following criteria:

Does the certificate common name match the domain name entered in the URL bar?
Is the current date between validity start date and validity end date?
Is the certificate signed by a well known Certificate Authority (CA)? (This is something you don't have with a self-signed certificate)
Does the certificate have been revoked? (I'm not sure all browsers validate this point)

There are also other mechanisms but let's forget them for now.

In your case, if you want to avoid this error message (which does not mean you don't browse your website in HTTPS), you can:

Remember your choice with Firefox (and you should not be warned again)
Sign your certificate with your own CA and install your CA as trusted in Windows and Firefox (there is a quite good article here, but it is not up to date due to the use of SHA1 signature instead of SHA2)
Get a valid certificate signed by a well-known CA (StartSSL for instance which is free)


Is server side CORS protection enough to mitigate CSRF attacks against stateless APIs? Assume an Angular SPA application on www.example.com that works invoking an API over that same domain www.example.com/api/...
The Angular app gets a session cookie and sends it in each API call.
The usual CSRF attack would try to execute a script with some API call, such as POST www.example.com/api/deleteUser when the user clicks an evil link www.evil.com.
The question is: if the API server has a properly configured CORS policy, allowing only www.example.com as origin, is it enough to mitigate CSRF attacks?

A CORS policy is not sufficient to protect against CSRF attacks in general, but might be in this specific case.
The question is, if the API accepts "simple" request as defined by the CORS specification. These are requests which can be triggered without JavaScript, i.e. by a form upload, embedding an image or similar. In this case the request will be send directly to the server and all what CORS could prevent is that the attacker could read the response. This is thus not sufficient to prevent CSRF, since CSRF about writing the request and thus executing the action at the server.
If the API instead accepts only non-simple requests (for example by requiring a custom HTTP header) then CORS will be a sufficient protection because in this case only a pre-flight request is needed before the actual request and based on the returned CORS policy from this pre-flight request the actual request will not be executed.


Virtualisation: security on the host side Virtualised environments are focused on isolating the guest OS. Using the VirtualBox model, the guest might be behind a virtual NAT and/or talk only with other VMs  via internal networks,  and only with the host via host-only networks.
All these  methods are meant to make the host invisible and unreachable from the outside internet, while allowing inbound connections from other VMs and host.

What if one runs  server services on the host for the guests?
Is it possible to shield the host from the outside world, while allowing inbound traffic from the guest machines?

A simple method would be restricting the listening ports on the host to the virtual machine/network IPs.
But another box sitting in the same network of the host might spoof the IP and pretend to be a VM. Outside the host  the gateway device might check for the actual IP of the spoofer matches its packet sources
But we don't know who is and how wary is the admin. So how can we manage security inside the host? For example have the host listening only to inbound traffic from VMs.

That is what VirtualBox's host-only networking mode is for. It creates a virtual network adaptor on the host and connects it to a virtual network adaptor in the guest.

Then you just tell the services running on the host to only listen on the virtual adaptor.

See section 6.7 of the VirtualBox manual for more details.


Does it make sense to have something similar to IPSec at the data link layer? We currently have security protocols for the application layer (e.g. S-HTTP, DNSSec, PGP, etc.), the transport layer (e.g. SSH, TLS, SSL, etc.) and the network layer (e.g. IPSec).

Does it make sense to create a security protocol for the data link layer?

There are good reasons to add security to the lower layers and it has been done in practice (see WLAN protocols). Providing data confidentiality and authentication services at the data link layer is a simple solution. It is attractive because the wireless link is typically the most vulnerable part of the connection and one has to deal with only network technology. Moreover, when a lower layer is secured, all upper layers are also secured. So it protects all protocol information from the higher layers. It also doesn't suffer from the interoperability problems that protection at the network or transport layer bring with them.

It does have the (rather big) disadvantage that the information is not protected in the intermediate network nodes. This makes it impossible to realize end-to-end protection.

For sensitive applications, protection at the data link layer can be combined with protection at a higher layer.


How does sync.com provide "zero knowledge" for web application upload? It is completely clear how desktop and mobile platforms for sync.com allow zero knowledge. However, it blows my mind when I try to understand how   "Zero Knowledge" could be theoretically possible when using a browser, i.e. web application upload.

So I login to sync.com with Chrome. Then I hit upload a file button, and a file from my PC is getting uploaded and encrypted on the fly by the browser? Then the browser must know my encryption key, i.e. my login password! Does  this mean the browser (and the sync.com) is keeping my login credentials while I'm logged in? As far as I know the credentials should not be kept like this, the modern practice is JWT token or something.

Anyway, does a browser even have such a complicated encryption capability (comparable with the desktop app), or are my files being uploaded to the server and encrypted there?
Either way that would not be a zero knowledge.

This is not how "zero knowledge" works.

Zero knowledge is on the context of your service provider, not the entire Universe. Being a Zero Knowledge Provider means they don't have and can't have the keys to unlock the data they host. In those cases, even if someone manages to get your files (stealing, leaking, or by government order), your data is encrypted and the provider cannot decrypt even by law, coercion, or financial interest.

In this cases, usually the application generates a random symmetric key, and an asymmetric key derived from your password. It used the asymmetric key to encrypt the symmetric, and used the symmetric key to encrypt your data. The encrypted symmetric key and the data are uploaded together. The provider only gets an encrypted key, and encrypted data with a key they don't have.

To decrypt things later, the application asks your password, uses it to derive the asymmetric key, downloads both the symmetric key and the data, decrypts the symmetric key, and uses it to decrypt the data.

The browser knows your key as long as you are logged in, as most of secure applications will invalidate the data on logout. Your browser (or desktop application, or Excel macro) must have the key, or they won't be able to encrypt or decrypt your data.

And a browser can encrypt things very fast, thanks to WebASM, so there's really no noticeable difference in speed unless you are encrypting lots (more than GBs) of data.


Key differences between X509 TLS Client certificate and server certificate Is there any difference between a X509 TLS client cert and a server cert?
I had been implementing certificate-based mutual authentication and hence trying to get/use certificates for IoT devices. While we are pretty clear on server certificates, I was wondering if the client certificates that individual IoT devices will load and present to the server for their authentication are same/similar to what is used for a server.
Will client certs also to be acquired from a CA and then they will be validated by a server via root CA cert in the same way as server cert is validated against the root CA?

Structurally, client and server certs are the same. Both will need keyUsage: digitalSignature and will contain the same type of RSA or ECDSA key. They chain to an intermediate and root CA via Issuer and AIA fields in exactly the same way as server certs. They handle revocation via CRL or OCSP in exactly the same way as server certs.
However, depending on the enforcement / authorization rules in your server, you may need to put different metadata in the client certs. For example:

Server certs almost always have a SubjectAltName of type dNSName matching the public domain name at which the server can be reached. This makes absolutely no sense for a client. Often instead you see a serialNumber DN component, or one of the less common SAN types.
Your server may be configured to require client certs to have the extendedKeyUsage: id-kp-clientAuth.
Your server may enforce groups, privileges or access controls based on policy OIDs or other custom v3 extensions.

Again, these are all "may" type items and will depend on how you've built your server; though I do recommend that you think about having some kind of access control rather than blindly accept any cert from your root CA.


Is it safe to keep a virus' binary code on your local machine? Is it safe to keep a file containing the virus (binary?) code on your local machine without executing it? I am testing my application against malicious file uploads and and wondering if it's safe to actually upload this virus into my application and let it store in the upload folder.

A virus binary is just like any other file. If it's not executed, then it is just data.

Note that there are other possible avenues that a virus could be activated without your consent. For example, if your computer is set up to automatically display thumbnail from an image file, and the virus exploits a buffer overflow in the image parser of the thumbnail generator, so you can accidentally execute the virus just by opening the directory where the virus is located. As long as you know the activation vector of the virus though, and you avoid those, keeping a virus file in the filesystem should be fine.

You should use an EICAR file if you want to test virus detection:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*


Is looking at certificate expiration date a valid way of detecting malicious websites? Whenever I buy something online or I receive bills on my mailbox with a link to pay via dotpay I always check if the page I am redirected to has a certificate valid for at least 1 year. Is it a good practice to do that or is it completely unnecessary? My reasoning is that if someone creates a scam website imitating my bank's website or dotpay website then they will probably have a certificate issued a couple of days ago and lasting only a month or so, because they know that page will be closed as soon as someone finds out it is a scam. Is this absurd or can it actually be used as a very quick way of partially validating if website is trusted?

No, it's not a proper way to check.  Long-lived certificates are largely falling out of favor because of the security implications, and are actually arguably less trustworthy than short-lived one.  The reasoning behind this is as follows:

Suppose you own a website and purchase a TLS certificate for it with a validity of 10 years.  Now assume that the key gets compromised on day one, and you never find out about this.  Whoever got a hold of the key for that certificate can now impersonate your website for the next 10 years.  If instead you had one that was valid for only 3 months, the amount of damage that attacker could do would be significantly less.

As far as actually checking whether a certificate is legitimate or not, there's not really anything you as a user can do.

Validity periods are out, because that's local policy.  Some people still want to pay through their nose for long-validity certificates, so you will still see such certificates in regular usage, especially among companies that have been using SSL/TLS for the longest (banks for example).
Issuance date is out too, for the same reason that validity periods are no good.  You might consider one right near the end of it's validity period to be questionable, but that's hardly going to be reliable.
Domain validation is out, as it's not hard for attackers to spoof the required DNS records (DNS is still one of the most insecure parts of the internet).
Extended validation is out, as it's largely a joke as most companies that provide it do it, and some popular companies just don't do it at all (largely because there really is near zero value to it for securing communications).

All the other checks you might do that look at the certificate itself are already done by your browser automatically (checking that the certificate is valid and hasn't been revoked, that the domai matches, and that the server has the associated key).

That said, you should be actively looking out for typosquatting, which may be a bit more obvious if you are looking at the certificate itself.  A better defense for this though is to make sure that your browser displays non-ascii characters in domain names in their escaped or punycode form.


Use GPG smartcard and gpg-agent to protect multiple SSH keys I have a Yubikey acting as a GPG smartcard. SSH is configured to use the smart card socket for authentication, and authenticating with the GPG key with Authentication capabilities work fine.

ssh-add -l
2048 SHA256:ey5VPl70RKvXSdaon6ugxiO1ZrzqxJwz7VWZM7zvN/c cardno:000607329647 (RSA)

I have some additional SSH keys that are used for SSH authentication to various servers. I can add these to the ssh agent with ssh-add somekey, but then I need to provide a passphrase per key. Is there a way to use the smartcard to protect these keys instead?

The desired end state is that multiple SSH keys are stored encrypted on disk, and the smartcard and gpg-agent is used to unlock and cache them.

The easiest solution I was able to come up with this morning uses Key Encryption Key principles for execution. This is fairly common when using multiple SSH keys on servers in the cloud. You can use a cloud based HSM to encrypt/decrypt the keys you need to use without having to store it locally. This was when your encrypted keys are left on the disk, and attacker doesn't have access to the master key.

To implement this within your environment you need the following:

A gpg configured Yubikey (or other GPG key system)
A target file to encrypt/decrypt
A slightly modified configuration file

For the purposes of this article, I'm going to assume the reader has already configured their Yubikey. If you haven't done this (I realize OP has), you can register your key with gpg with these directions:

https://support.yubico.com/support/solutions/articles/15000006420-using-your-yubikey-with-openpgp

The first thing you'll want to do is determine which key you want to perform the local encryption and decryption. Try running:

gpg --list-keys

This will output a few lines. We need the content of the PUB line for the key associated with the yubikey:

pub   2048R/E48EFBC7 2019-01-20

Specifically, we need the 8 characters "E48EFBC7". Once we have the characters, we can copy them to our configuration file to ensure we use the yubikey key by default. To do this, update the following line in the gpg.conf file (~/.gnupg/gpg.conf):

default-key E48EFBC7

By default, this line is commented out, you'll need to uncomment it. As a side note, this is NOT required, but it is helpful. Instead of trying to specify a key for encryption, you can make the application leverage your Yubikey by default.

The next configuration will be altering the recipient. Again, this is optional but definitely helpful. Scroll down and uncomment the following line within the gpg.conf file:

default-recipient-self

Now your gpg agent is set to automatically use your yubikey for encryption/decryption and to make the target recipient your encrypting key.

With this in place, you can now start encrypting and decrypting your certificates. To encrypt simply run the following command:

gpg -o <output.gpg> -e <ssh.key>

To decrypt;

gpg -o <ssh.key> -d <output.gpg>

Decryption will ask for your Yubikey PIN.

Some finer notes:

Run a chmod 600 on your ssh keys when they are un-encrypted to make sure only the direct owner has permission to read the key.
Remove decrypted keys when they are not longer needed.
You can still add a key to your ssh keys to protect them even when they are decrypted.


OMAC: multiplication in a finite field - how can I compute the correct polynomial From The EAX Mode of Operation:

  We explain the notation used in the deﬁnition of OMAC. The value of iL (line 40: i an integer in {2, 4} and L ∈ {0, 1}n) is the n-bit string that is obtained by multiplying L by the n-bit string that represents the number i. The multiplication is done in the ﬁnite ﬁeld GF(2n) using a canonical polynomial to represent ﬁeld points. The canonical polynomial we select is the lexicographically ﬁrst polynomial among the irreducible polynomials of degree n that have a minimum number of nonzero coefﬁcients. For n = 128 the indicated polynomial is x128 + x7 + x2 + x + 1. In that case, 2L = L << 1 if the ﬁrst bit of L is 0 and 2L = (L << 1) ⊕ 012010000111 otherwise, where L << 1 means the left shift of L by one position (the ﬁrst bit vanishing and a zero entering into the last bit). The value of 4L is simply 2(2L). We warn that to avoid side-channel attacks one must implement the doubling operation in a constant-time manner.

I was basically just given that the polynomial to use in the finite multiplication for n = 128 is x128 + x7 + x2 + x + 1.  I want my implementation to be abstract in that it isn't reliant on the specifics of the cypher being used.  To allow the block size n to be any number rather than hardcoding 128 or a few others, how can I have my software compute the correct polynomial?

Don't.  For most people, there is no reason to implement your own crypto library.  Get an existing crypto library with an implementation of CMAC (aka AES-OMAC1), and use that code.   Implementing it yourself is error-prone (with the risk of security problems) and often misses out on performance optimizations found in standard libraries.  For most purposes, there is no reason to implement it yourself, and little reason to use any other cipher than AES, or in particular, a block cipher with anything other than a 128-bit block size.


Privacy of web surfing by Free gate I am connected to the internet in the university where I don't want the administrator or any organization to find out some of the websites and contents I check in them.
I'm afraid that they might trace me back through the IP or Mac addresses.

First I use a Firefox private browsing window to not leave a trace on the computer.

Then I use FreeGate proxy software from DynaWeb, in this FAQ, they claim it is safe to use Freegate to surf the Internet.

All Internet communications are encrypted.
Local surveillance systems cannot detect what you are doing.

It uses F and A tunnel modes. sometimes I use A and if its slow I use F in other computers or Networks.

Am I safe with the scenario above?

If their encryption is indeed secure, it would ensure that anyone who can eavesdrop on your connection between you and their server will not be able to find out what you are doing. This is a very big if because they don't provide any details on their FAQ about what algorithms they are using and how they use them. Their FAQ only mentions "our proprietary technology" which is a yellow flag. A good cryptosystem isn't afraid of publishing their algorithms. When they try to hide it, it might be a sign that they are rolling their own crypto and then rely on security through obscurity because they don't trust it themselves.

However, there are a few other attack vectors.

Can you trust them? When you are visiting a website which uses http and not https, the connection between DynaWeb and the target website is unencrypted. That means DynaWeb is theoretically able to monitor your whole internet activity.

Even when the website uses https, DynaWeb still knows which webservers you connect to. They don't know the exact URLs and what you do there, though.

Someone could eavesdrop on DynaWeb's outbound connection. They might not be able to tell from which customer each connection originates, but when the data is unencrypted (http), they might be able to tell from the content of the transmission.

When an attacker can eavesdrop to both Dynaweb's outbound connection and your connection, the can perform a traffic correlation attack to find out what you are doing. Encryption can hide what your communication is about, but it can't hide when you communicate and how much.

546 encrypted bytes going from you to Dynaweb
12ms later 546 encrypted bytes going from DynaWeb to https://extremelyillegalwebsite.example
145ms later 1152983 encrypted bytes comming back from https://extremelyillegalwebsite.example  to Dynaweb
13 ms later 1152983 encrypted bytes going from DynaWeb to you

What could you possible be doing?


How is this XSS attack working? SPOILER ALERT: This question contains an answer to one of the problems from the Google's XSS Challenge! Please stop reading further if you're not interested in knowing the answer right now.

I'm able to get pass the level 4 of the challenge, however, I still don't know how exactly the exploit is working. The following is the code from Google's XSS challenge - Level 4:

<!doctype html>

    <link rel="stylesheet" href="/static/game-frame-styles.css" />

Your timer will execute in {{ timer }} seconds.

Basically, they are using Django framework (which uses a bunch of security measure against XSS). The variable timer carries the input from the user. The goal of this activity is to alert a message by sending a payload which can bypass Django's XSS security.

I'm able to alert a message using one of the following payloads:

');alert('xss

OR

3') || alert('1

I'm able to clear the level using the above payloads but I'm still not sure where exactly the alert() method is being called? In the onload handler OR within the startTimer() method?

I'm confused because if I check the source HTML of the page after submitting the payload, Django is encoding the payload:

    <link rel="stylesheet" href="/static/game-frame-styles.css" />

Your timer will execute in &#39;);alert(&#39;xss seconds.

What happens is that the HTML output is:

{{ timer }} is a variable which gets "translated" to whatever the ?timer GET parameter is. So suppose we have a legit parameter: ?timer=3. It gets "translated" to:

But what if you put some code in timer? 3');alert('xss');//

As you can see, the logo loads, and once it loads, the onload callback is executed. There's the vulnerability.

P.S. it's not in startTimer itself, because it parseInts the variable, and it removes everything but numbers, essentially 3'); ... becoming in 3.


Why am I unable to connect to an address spoofed with arpspoof? I wanted to see how many combinations of websites and browsers are still vulnerable to a tls stripping attack (like, by implementing HSTS or disabling cleartext HTTP altogether). To do it I wanted to see it firsthand by using the sslstrip tool, but I was unable to get it working (by following the instructions on the project page itself): the ARP spoofing apparently is working fine, since the target pc cannot browse anymore, but sslstrip doesn't receive anything.

I tried to listen with a TCP socket on the port redirected by iptables, but I received nothing, so I excluded also iptables, and now I'm just trying to receive connections directly on the port used by the victim client. I tried by both enabling and disabling ip forwarding (with /proc/sys/net/ipv4/ip_forward), and using wifi or ethernet as the interface from the attacking host, but nothing changes:

This is the command I'm using from the attacking host (address 192.168.1.33 hostname macbook, a Linux 3.11 box):

sudo arpspoof -i eth0 -t 192.168.1.31 192.168.1.1

(192.168.1.1 is the gateway) and then

sudo socat TCP4-LISTEN:80 STDOUT

on the victim host (192.168.1.31):

socat - TCP4:192.168.1.1:80

I can open the connection, but if I try anything, I don't receive anything on the attacking host (pointing socat to the attacker's ip address obviously works)

traceroute shows that apparently the ARP spoofing is successful:

> traceroute 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 60 byte packets
 1 macbook.local (192.168.1.30) 2.719ms 5.932ms *
 2 * * *
 3 * * *
 4 * * *
 5 * * *
 [snip]
28 * * *
29 * * *
30 * * *

arp -n output from the victim host

Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.33             ether   00:1d:4f:fc:af:fc   C                     wlan0
192.168.1.1              ether   00:1d:4f:fc:af:fc   C                     wlan0

There's an IP collision going on.  Although you've convinced 192.168.1.31 that you're 192.168.1.1 with the following command (meaning you've influenced its routing table):

sudo arpspoof -i eth0 -t 192.168.1.31 192.168.1.1

... the 192.168.1.1 still thinks its 192.168.1.1, so when it sees arp requests for its own IP both your machine and the router will respond with a MAC address. The first MAC address received will be the one to get the packet (don't think that because you see an entry for your poisoned IP in arp -n that arp requests for that IP will necessarily cease). Also, it doesn't know NOT to send packets to the victim machine, or to respond to other packets that appear to come from that machine.

Typically, man-in-the middle is just that, "in the middle" so you should try the following:

sudo arpspoof -i eth0 -t 192.168.1.31 192.168.1.1

sudo arpspoof -i eth0 -t 192.168.1.1 192.168.1.31

The second one tells your router to send packets addressed to IP 192.168.1.31 to you (rather than the original victim machine). If your victim machine gets a packet from the real 192.168.1.1 with the real MAC address of that machine, do you know what it's behaviour will be?  So it's best to avoid this possibility by redirecting any packets from the real 192.168.1.1 destined to 192.168.1.31 to you, since you're suppose to be in the middle.


Is it a security vulnerability to tell a user what input characters are valid/invalid? For input validation on a website, are there any security concerns with disclosing to the user exactly what characters are valid or invalid for a given field?

CWE-200: Information Exposure says one should try not to disclose information "that could be useful in an attack but is normally not available to the attacker". A specific example would be preventing a system from exposing stack traces (addressed by CWE-209: Information Exposure Through an Error Message).

Should one ensure that error messages are vague, like "The text you entered contains invalid characters"?

Is it a security vulnerability to include the regular expressions used to validate input in client-side code, such as JavaScript, that would be visible to attackers? The alternative, validating inputs server-side, would reduce usability somewhat as it would require more backend communication (e.g. it could cause the site to respond and display errors slower).

Or is this a form of "security through obscurity" as the user/attacker can deduce what characters are valid by repeatedly submitting different characters to see if they produce errors?

Is it worth the hits to user experience to potentially slow down an attack?

I should note, as far as I can tell, OWASP's Input Validation Cheat Sheet and Data Validation development guide don't provide direction on this topic.

Edit 2020-01-17:

There have been several questions (including answers that I went to the effort of writing comments on that have since been deleted) as to why one should be doing any input validation.

First off, thank you to @Loek for the comment pointing to OWASP's Application Security Verification Standard that provides guidance on passwords on page 21 and 22: "Verify that there are no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters.".

I think we can all agree that limiting characters in a password is generally a bad idea (see @Merchako's answer). As @emory points out it probably can't be a hard and fast rule (e.g. I have seen many mobile apps that use an easier to use secondary "PIN" to secure the app even someone else has access to log into the device.) I didn't really have passwords in mind when I asked this question but that's one direction the comments and answers went. So for the purposes of this question let's consider it to be for non-password fields.

Input validation is part of "defense in depth" for websites, web services, and apps to prevent injection attacks. Injection attacks, as stated by OWASP, "can result in data loss, corruption, or disclosure to unauthorized parties, loss of accountability, or denial of access. Injection can sometimes lead to complete host takeover. The business impact depends on the needs of the application and data."

See OWASP's #1 vulnerability, A1-Injection, and CWE-20: Improper Input Validation for more detailed information. Note they both say input validation is not a complete defense but rather one layer of that "defense in depth" for software products.

... that could be useful in an attack but is normally not available to the attacker

Knowledge of invalid input characters are useful but can easily be found by the attacker with just a few tries. Thus this information is not really secret and keeping all users unaware of what exactly went wrong does not actually deter attackers, it only keeps innocent users away since they cannot continue.


A tale of two sources: Is TLS *defense* against Man-in-the-Middle, or not? We have recently used a security scanning tool to assess security of an application.  It raised a particular configuration as a Medium vulnerability.  The claims made in the explanation of the discovered vulnerability don't seem to match with industry standards.

The claim is that "transport mode" security is insecure:

  "Transport mode is the least secure option and should be avoided."

This quote above comes from this article relating to WCF security:
https://vulncat.hpefod.com/en/detail?id=desc.semantic.dotnet.wcf_misconfiguration_transport_security_enabled#C%23%2fVB.NET%2fASP.NET

The claim here made by HP appears to be that transport layer security, including SSL and TLS, is less secure than message-based security.  The article further explicitly states that TLS is susceptible to man-in-the-middle (MITM) attack.

Further research into MITM attacks seems to indicate that the opposite is true:  TLS is the preferred way to prevent MITM attack.  Resources supporting TLS include:

https://en.wikipedia.org/wiki/Man-in-the-middle_attack

https://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication/477578#477578

Do client certificates provide protection against MITM?

So, the question is:
Is there any merit in the claim, by the HP article, that transport-mode security is to be avoided, for the reasons cited in that article?

UPDATE: To add some context- the use case in our situation is calling a webservice, not a public site.

To cite the important part from the article you refer to:

  The disadvantage is that this kind of security is applied separately on each hop in the communication path, making the communication susceptible to a man-in-the-middle attack.

TLS is used in different use cases. Some of these cases involve a single end-to-end transport of the message, for example by having a client sending a message to a web server which then gets directly processed by the server. TLS successfully protects against man in the middle attacks in this case.

But TLS is also used when multiple hops are involved. In this case the transport is only protected with TLS between these hops but a man in the middle on any of these hops can intercept the unencrypted data. This use case is typical for mail (i.e. SMTP) but you also find it with HTTPS when using a reverse proxy, content delivery network or similar. In these cases TLS provides only hop-by-hop security but not end-to-end security. The latter can be achieved by encrypting the message before transport and decrypting it after the full transport (i.e. all hops) is done. For mail this is usually done with PGP or S/MIME.


How to troubleshoot why Thunderbird rejects a PKCS#12 certificate with "Could not verify this certificate for unknown reasons"? After playing around a bit with openssl, I created a PKCS12 certificate which imports flawlessly in Firefox while Thunderbird "Could not verify this certificate for unknown reasons". Talk about a helpful error message here. While I managed to solve the problem (the certificate had an extendedKeyUsage of emailProtection,clientAuth while the signing CA had emailProtection only - why did Firefox import it then?!) in this case, I'd like to know about a less trial-and-error way to figure out why a specific certificate fails.

I could find a large number of threads and bug reports, e.g. this, which suggest whatever library is internally used does actually provide more meaningful error messages, but I don't have an idea where to start calling it or whether some simple command line tools exist to achieve this. So in summary:

  How to figure out why a Mozilla product rejects importing a certificate "for unknown reasons"

Last I had to do something like that, I ploughed through NSS source code. NSS is the library which Mozilla products use for all things crypto. Ultimately, you could compile your own Thunderbird and run it in a debugger (or spread printf() calls throughout the NSS code, for some old-style analysis).

Apart from that, it is mostly guesswork. You did it quite well: by importing the same certificate into Firefox and Thunderbird, both using the same NSS code, you actually showed that the detail you were after had to be something about emails -- which then points to extended key usage and "usage rules" that NSS can attach to a given root.

At least, NSS is opensource. Try doing the same for Windows/IE next time...


How to mitigate the new malicious USB cable USBHarpoon (NOT BadUSB) threat in an enterprise? In this case, the victims may think they are using a generic USB cable, but the PC will recognize the cable as a Human Interface Device, much like it would a mouse or keyboard, giving the attacker just enough permissions to wreak havoc inside the system. This is different from all the other variations as this threat is much trickier to address with awareness practices.

https://www.bleepingcomputer.com/news/security/usbharpoon-is-a-badusb-attack-with-a-twist/

https://www.tomshardware.com/news/malicious-usb-cables-wi-fi-controller,38603.html

Depends on your OS.

If you're on Windows you can use Penteract Disguised-Keyboard Detector which will lock the screen when it detects any HID.

If you're on Linux, I think there exists software that whitelists or blacklists USB devices, therefore avoiding the need for awareness.


Which browser does not allow "remember me" option? As all the modern common browsers like IE, mozilla, chrome overrides the "autocomplete=off" feature and ask to remember the username/password, is there any not-so-popular modern browser which does not even ask the user to remember the user credentials?

As all the modern common browsers like IE, mozilla, chrome overrides
  the "autocomplete=off" feature and ask to remember the
  username/password,

Technically Chrome (and others) do not save for autocompletion; they save them to the password manager.  These are two different things and the latter is not proscribed by autocomplete=off.

In Chrome and Firefox the separation from autocompletion, and the use of a more sophisticated password manager, is clear.  In IE it's not; even though the passwords are stored in the Credentials Manager the option is still listed under "AutoComplete"... Caveat Microsoft :)

  is there any not-so-popular modern browser which does not even ask
  the user to remember the user credentials?

I do not know of one, but if you don't like this behavior it's easy to turn off.

In Chrome:

Go to Settings -> Advanced -> Passwords and Forms
Uncheck "Offer to save your web passwords"

In Firefox:

Go to Options -> Security
Uncheck "Remember logins for sites"

In IE:

Go to Internet Options -> Content
Under AutoComplete, click Settings
Uncheck "User names and passwords on forms"


How secure is KeePass KDBX4 by default? How secure is KeePass KDBX4 by default if someone obtain the .kdbx file and attempt to brute-force it without knowing any hint of the master password?

With assumption :

The password length is equal/more than 20 character
Password is chosen from a book and tweaked (by change some alphabet into number)
Database file encryption algorithm (default option) : AES/Rijndael (256-bit key, FIPS 197) as
Parameter for Key transformation (default parameter) :

Key derivation function : Argon2
Iterations : 2
Memory : 1 MB
Parallelism : 2

P.S. i know there's similar question at How difficult to crack keepass master password?, but it was created before KDBX4 released

P.P.S. parameter above is default parameter generated by KeePass 2.42.1

KDBX4 can now use Argon2 which is the state-of-the-art in password derivation.

The difficulty to guess the password of a KDBX4 database depends on:

The chosen Argon2 parameters, which are poorly advised by Keepass, but still better than the previous AES-KDF. The parameters you describe are very poorly chosen, they will not strengthen by much the resistance of the password.
How well was chosen the master password. From what you describe, the password is vulnerable to a dictionary attack.

To summarize, the confidentiality of this database is probably breakable with enough resources (including an appropriate dictionary) in a reasonable amount of time. A proper estimate of the time and financial cost is out of scope here.


Network Security with EAP: PEAP and Phase 2: MSCHAPv2? I want to connect to my college WiFi but I’m worried about the security (data leakage, hacks, MITM). The configuration I used to connect to my college WiFi is as follows:

EAP: PEAP

Phase 2: MSCHAPv2

Identity: [my ID no.]

Anonymous Identity: [ *I left this blank* ]

Is this network secure to connect?

There really isn't enough information here to provide any definite conclusion. However, based on the information you provide, I would assume that the configuration is using PEAP with EAP-MSCHAPv2, which would indicate the MS-CHAPv2 is being tunnelled through a TLS connection and therefore should be reasonably protected against the vulnerabilities in plain MSCHAP.

Whenever you connect to any network, wired or wireless, there is a level of implicit trust - you are trusting that the system has been configured correctly by the admins, that the hardware is secure with up-to-date firmware and that the admins are trusted and know what they are doing. If you are not confident about all of this, my recommendation would be to consider your operating in a hostile environment and to take measures to reduce your exposure. Things you can do include

Ensuring you use different passwords wherever possible. Don't use the same password for your wifi connection as other sites/services. If someone is able to get your network credentials, they won't be able to use that information to access other data/services
Always use HTTPS rather than HTTP whenever possible. This will ensure that even if someone is able to sniff your network traffic, they only see encrypted data
Consider setting up a VPN or SSH tunnel inside your connection. For example, when I sometimes have to use an untrusted public wifi network, after connecting to the network, I establish an ssh tunnel to a trusted server and then forward all my traffic through that tunnel. As this tunnel is encrypted, the amount of information accessible by anyone sniffing the traffic is minimal. A VPN connection will achieve a similar result.

It may be worthwhile contacting your college IT department and asking to speak to someone about security and network configuration. They will probably be able to provide you with guidance on how to ensure your connection is safe etc. This may also help to determine how confident you are regarding the college setup etc.


How do I scan for GHOST remotely? I'm talking about CVE-2015-0235.

I figured there's no Metasploit package for this kind of check yet and I also understood that there's a special VM by Qualys for this test.

Do you guys know of any other possibility of testing this vulnerability from outside the network?

Alternatively, can anyone tell me if there's any way to tell if this vulnerability is effective behind load balancer?

The nature of the CVE-2015-0235 makes it impractical to scan remotely. The glibc library is used by many applications which may or may not be exploitable depending on what parts of glibc they use.

Your best bet is to identify which of your systems (they are your systems right?) are using the outdated version of glibc and patch accordingly. Consult with your distribution's maintainer to identify the packages and versions impacted. If you have many systems and don't already have a central patch management system in place, you may be able to write a script to help you identify what versions you're running where.

I don't see any reason that a system behind a load balancer couldn't be vulnerable. Again, it depends on the specific applications used and the setup, but in general, this vulnerability could still be exploited on a system behind a load balancer.


Is it secure to use CORS to implement SSO? I implement SSO to integrate some web login mechanism to the centralized member system which is OAuth2 provider.
And currently OAuth2 authorization works well.

However, I would like to implement much more smooth login methods by AJAX call.
For example, user logged in web A and member system already. When user navigate to web B, the web B should call AJAX to member system to see whether user logged in or not?
If user logged in, the web B should show user the logged in page.

I have studied some of OAuth2 article (I cannot find link now). They all do SSO by redirect to OAuth provider directly.
However, I would like to use CORS AJAX call because it could provide better UX.

I read another discussion about the risk of CORS and SSO: Designing single-sign-on with JSONP/CORS?

But I cannot understand the selected answer.

  There must be a control in place to prevent a malicious JavaScript
  client from falsifying interactions with the authorization server. If
  the URL is supplied as an argument within a CORS Ajax request, rather
  then checking the HTTP origin header, then a malicious client is
  permitted to lie about it's context.

The URL could be verified by CORS header Origin.

My opinion is that if OAuth2 Provider set CORS Origin correctly, it should be fine to support CORS AJAX login mechanism.
Because cookie and CORS cannot access by cross domain and violate CORS Origin strategy, it would not suffer CSRF attack. Only need to worry about XSS.

I am not very confident about my opinions, that's why I post here.
If you have any advise or find my error, please let me know.

[Update More Detail]
In member system, I would define CORS settings like this

app.use(cors({
   origin: ["http://weba.com", "http://webb.com"],
   credentials: true,
   methods: ['GET', 'POST']
}))

app.get('/sniff', (req, res)=>{
    if(req.session.user){ res.send("user login")}
    else res.send("not login yet")
})

In the webA,

xhr.withCredential = true
xhr.open("GET","http://member.com/sniff") => I can tell if user login or not.

Over and above the advantage of only having to deal with one user database, there are 2 important security benefits of using SSO:

1) The application should never see the credentials - thus removing some of the attack surface

2) since the browser redirects to the SSO site, the user can easily verify that they are supplying their password to the appropriate system under appropriate controls (TLS, HSTS).

What you propose seems to directly undermine 2, and, since the client will be pointed to the SSO by the application, your proposal indirectly undermines the first benefit.


Is the undesirable conversion of a scientific number a vulnerability? I noticed in several penetration tests that PHP is converting values like 1e9 to 1000000000 while the max accepted string length of this number is 3 (in the database storage and as maxlength property on the HTML forms).

Nevertheless, when inputting 1e9 (3), PHP will return 1000000000 (10) as its output. That is a higher number than the application expects and can properly handle. Therefore I would consider a better validation of user input to prevent this.

Firstly, I assume this behavior is not dangerous but just undesirable, is it legitimate to assume this? Secondly, can I consider this as an actual (low severity) vulnerability?

Also the input 9e9 will result in the max 32-bit value 2147483647 (10) instead of 9000000000 (10). Is this alone (32-bit system or configuration) considered as leakage of system information or dangerous anyhow?

Why does this happen?

It's because PHP has loose typing. Take a look at this example:

$x = "1e6";
echo strlen($x); // 3
echo $x * 1;     // 1 000 000

On the second line, $x is assumed to be a string, and as such is obviously three characters long. On the third line, $x is interpreted as an integer, or 1 000 000 in this case.

Is it a problem?

This can definitely cause bugs, and every bug is a potential security vulnerability. But on it's own, it does not make your application vulnerable by default. But lets try to imagine a scenario where it would cause a problem.

Let's say a forum has numbered groups that users can freely join, but the first 10 groups (0 to 9) are reserved for administrators. The code for joingroup.php looks like this:

$group = $_POST['group'];
if(strlen($group) > 1 || $isadmin) {
    join_group($group, $uid);
}
else {
    // Fail.
}

You could sneak into an admin group without actually being an admin by posting e.g. 0.3e1, that has string length 5 but evaluates to 3. I know, it is a silly example. The point I want to make is that if you rely on strlen() (or anything else that treats the input as a string) to validate numeric data, you might be vulnerable.

Just posting 3.0 or  3 would bypass this check as well. For more on how PHP implicitly converts strings to numbers, check the manual.

How should I deal with this in PHP?

Validate user input. Check that you actually get an integer when you expect to get an integer:

if(!ctype_digit($group)) {
    // Fail.
}

It is also a good idea to always treat something that should be an integer as an integer and not a string:

$group = (int) $_POST['group']
if($group > 9 || $isadmin) {
    // ...

Is this leaking system information?

Apparently this can reveal the maximum integer value. Perhaps someone could deduce that you are using PHP from this, but there are probably many other ways to do that already. The max value is platform dependent, so it could be used for fingerprinting. But in practice 32 bits are probably used on a 32-bit system, and 64 bits on a 64-bit system. So that is the only information you are leaking.


What are the security trade offs between the different methods for encrypting a guest VM image? The scenario is a lightly secured home or work PC used primarily for low-sensitive operations. For more secure activities a pre-built and restrictive virtual machine will be used.

I'm mostly concerned about data theft and/or modification via unauthorized/unattended access to the host machine while the VM is powered off.

For mitigation, I want to encrypt the VM image, and it seems there are three general choices:

Use VeraCrypt or another on-the-fly encryption package to encrypt the partition or folder where the guest VDI will be stored.
Use VirtualBox's or VMWare's built-in encryption to encrypt the guest image.
Use full-disk encryption within the guest OS (e.g. LUKS for guest Linux or BitLocker for guest Windows)

What are the security factors or tradeoffs between the three? Is one generally more secure or more tested than others?

It seems like 1 and 2 might amount to the same thing. I know VeraCrypt has been audited, and LUKS seems pretty well-tested, but not sure about the encryption build into VM software.

note: This answer is for a similar question, but the answer does not address the trade-offs between the three choices

Your mindset is backwards.  In a hypervisor scenario where you want to use both the host and guest(s) as usable machines, the most secured 'machine' must be the host.

To try and drive this point home:

if your 'more-secure' VM is a guest and you use the
host to surf the internet, then any compromise of your 'less-secure' internet surfing host provides automatic access to any and all guests.  Encrypting the VMs disks only protects the disks when the VM is offline AND that assumes the attacker doesn't know how to pull the keys out of memory (which they would have access to since they would be attacking from the host to the guest)
if your 'more-secure' machine is the host and you surf the internet from the guest, then an attacker would have to either attack over the network or through the hypervisor--both that are considerably harder than having implicit rights to manipulate the hardware of the VM.

And while this doesn't answer your question directly, if you choose to flip the route you're taking, just drive encrypt the host's hard drive and all others are automatically included (assuming they're all on the same disk)


How to Find a Zombie candidate for Zombie Scanning? I know how to do a zombie scan but my question is how do you find a zombie host?

You can read the documentation of nmap here, who have a section "Finding a Working Idle Scan Zombie Host".

It explain that you must find a host with IPID sequences of either Incremental or Broken little-endian incremental.

You can use a command like sudo nmap -sA -O -v <IP> and find which host has a Incremental or Broken little-endian incremental IPID.


is the entire cipher-text needed for decryption in asymmetric encryption? in symetric encryption it is different. however in asymetirc encryption lets say we have a part of the cipher text only,not the entire ciphertext. you also have the private key. can you decypt that specific part of the cipher text with the private key

Most practical asymmetric encryption uses symmetric encryption to encrypt the bulk of the data, so many of the same design principles and design considerations in symmetric encryption also applies to asymmetric encryption.

In most practical asymmetric encryption, the asymmetric encryption is used to encrypt a symmetric session key and to sign. As long as the partial ciphertext includes the header block where the session key is stored, you'd be able to decrypt partial asymmetric encryption if the underlying symmetric encryption can be decrypted with partial text. You'd most likely get a signature error, but this don't prevent the partial decryption itself.

If you're asking whether pure RSA or EC itself can be decrypted with partial text, as implemented in most practical encryption system, then no, as these asymmetric ciphers are used only to encrypt a single block (the symmetric session key), so no block chaining vulnerability would be possible.


Exposed my browser cookie of my request header I exposed my browser cookie of my request header in a web forum.
After I realized what I have done - I logged out, cleared my browser and logged in again.
Am I safe now? Can someone still use that browser cookie to impersonate me?

Can someone still use that browser cookie to impersonate me?

As @Hackndo noted, this is totally up to the web-developer.

am I safe now

Guessing, I would suggest you change your password, not just log out.
Here is a deterministic way to check:

Now take your cookie, then log in (or change your password) and compare the 2 keys to see if they are the same.

if they are not the same, make an http request with your old key, and see if it is valid. You say that it is stored in cookies, if so you can use curl to send cookies. If the key is stored in it's on header (cookies are seperate), something like this

GET / HTTP1.1
Authentication-Key: "some_key"
Cookies: cookie1=something;cookie2=comething;

you can still use curl to define custom headers.
If the Authenticaiton Key is not send with either of these formats, you'll have to replicate your browser's behavior by looking in the network tab.


Duplicate subject names for intermediate and root certificates I work in an organization which is employing what I believe to be a non-standard and problematic PKI system for internally used certificates.

They issue multiple root certificates and intermediate certificates with the same subject name with different validity periods. The public keys are also different.

When I look up an Issuer Name it gives a subject which could match multiple different certs. Some underlying implementation must be determining which cert is the actual issuer.

OpenSSL hashes certificates according to their subject and installs them in a particular place. It does allow duplicate hashes and creates multiple sym links.

I think we have faced problems in dealing with these multiple root and intermediate certs on servers. Sometimes deleting an unused expiring cert has caused TLS to fail. I don't know if this because of this re-using of subject lines and a problem with OpenSSL getting some order messed up. Or it is some other issue and this duplicate subjects for root and intermediate certs is normal.

I would appreciate any feedback on this. I searched the RFC document and saw this but found it confusing because it refers to a subject entity which I assume is the real world entity. So I believe this says you can issue multiple certs for the same real world entity with the same subject. Which is fine. But my question is around intermediate issuer certs.

  Where it is non-empty, the subject field MUST contain an X.500 distinguished name (DN).  The DN MUST be unique for each subject entity certified by the one CA as defined by the issuer field.  A CA MAY issue more than one certificate with the same DN to the same subject entity.

It is the combination of Subject Name and Public Key which makes a certificate unique. If either of those change, it is a completely different certificate as far as verification is concerned.  It can be either or both.

It just confuses us humans when only the Public Key changes while the Subject Name remains the same.

Therefore, in your case, the names are the same; but the keys aren't.  That is, they are two different certificates that belong to the same CA.

To aid the comparison process, many CAs add a Subject Key Identifier (SKI) and Authority Key Identifier (AKI) extensions to certificates they sign.  The values in these extensions are derived from the Public Key (of the Subject for SKI and Issuer for AKI); usually in the  form of a SHA-1 hash. With these in place, it's now a matter of comparing a relatively short hash rather than the much longer public key.


Why is there a need to modify system call tables in Linux? I have been learning about rootkits recently and have noticed this hooking techniques that kernel-land rootkits use in order perform malicious actions.

Where a typical hooking operation would be to hook on to a legitimate system call, and then replace the legitimate action with the malicious action first, before actually calling the legitimate action.

But if that is the case, why not make the system call table to be unmodifiable from the start?

You can check if they are read-only by looking up the kernel symbols. The "R" means read-only.*
$ grep sys_call_table /proc/kallsyms
0000000000000000 R sys_call_table
0000000000000000 R ia32_sys_call_table
0000000000000000 R x32_sys_call_table

So they are read-only, and have been since kernel 2.6.16. However, a kernel rootkit has the ability to make them writable again. All it needs to do is execute a function like this† in kernel mode (directly or via sufficiently-flexible ROP gadgets, of which there are plenty) with each address as the argument:
static void set_addr_rw(const unsigned long addr)
{
    unsigned int level;
    pte_t *pte = lookup_address(addr, &level);

    if (pte->pte &~ _PAGE_RW)
        pte->pte |= _PAGE_RW;
}

This changes the permissions of the syscall table and makes it possible to edit it. If this doesn't work for whatever reason, write protection in the kernel can be globally disabled with the following ASM:
cli
mov %cr0, %eax
and $~0x10000, %eax
mov %eax, %cr0
sti

This disables interrupts, disables the WP (Write-Protect) bit in CR0, and re-enables interrupts. Using assembly lets this work despite write_cr0(read_cr0() & ~0x10000) failing due to the predefined function for writing to CR0 now pinning sensitive bits. Make sure you re-enable WP after, though!
So why is it marked as read-only if it's so easy to disable? One reason is that vulnerabilities exist which allow modifying kernel memory but not necessarily directly executing code. By marking critical areas of the kernel as read-only, it becomes more difficult to exploit them without finding an additional vulnerability to mark the pages as writable (or disable write-protection altogether). Now, this doesn't provide very strong security, so the main reason that it is marked as read-only is to make it easier to stop accidental overwrites from causing a catastrophic and unrecoverable system crash.
* The particular example given is for an x86_64 processor. The first table is for syscalls in native 64-bit mode (x64). The second is for syscalls in 32-bit mode (IA32). The third is for the rarely used x32 syscall ABI that allow programs to use all the features of 64-bit mode (e.g. SSE instead of x87 for floating point operations) while using 32-bit pointers and values.
† The kernel's internal API changes all the time, so this exact function may not work on older kernels or newer kernels. Globally disabling CR0.WP in ASM however is guaranteed to work on all x86 systems regardless of the kernel version.


Does attacking difficulty of a block cipher depend on it's block length? Does attacking difficulty of a block cipher depend on it's block length compared to a substitution cipher?

Does attacking difficulty of a block cipher depend on its block length

It depends on many things, and block length is part of it. A small block size (64 bit) is vulnerable. However, as soon as you reach a reasonable block size, increasing the block size does not really make things more secure. So I wouldn't say a 256 bit block size would be much safer than a 128 bit block size.
Besides block size, another property of block ciphers is they key size. These do not have to be the same. In general, larger keys are more secure, but here also there are diminishing returns when getting sufficiently large.

compared to a substitution cipher

Block ciphers are usually compared against stream ciphers. I wouldn't say one is more secure than the other.
Even if the cipher itself is perfectly secure, whether the system as a whole is secure depends on whether the cipher is used correctly.


Does base64 encoding an image and storing it in a database introduce risk for XSS Ok, here is a scenario for you here.

You have a database.  You have a table in it that you will store small 30x30 pixel PNG images.  They are base64 encoded.  They will be echoed out as an avatar for the profile.

I have seen tricks in the past with XSS that use image tags to retrieve javascript code.

 <IMG SRC="http://www.thesiteyouareon.com/somecommand.php?somevariables=maliciouscode">

Can this be done with a base64 encoded image?  Is an attacker capable of crafting something that can introduce this sort of risk?  If so, what can I do to mitigate the threat?

Assuming you're handling the image data in a sensible manner, no.  The data never gets put in a place where it could be seen as code.

Even if you're not handling the image data in a sensible manner, probably not.  The base64 "alphabet" is missing some of the characters essential to producing useful Javascript -- there's only so much you can do with +, /, =, and the alphanumerics.  Without parenthesis, brackets, semicolons, spaces, or quotation marks, you can't construct an SQL injection or a Javascript function call.


Chinese hieroglyphs appear on screen when signing out of windows For some time now, when I try to sign out of windows or restart my computer, a message appears that a program forbids my computer from signing out and this program is a .exe  file with Chinese hieroglyphs for a name and I can't understand where it comes from. The last time I signed out, instead of them it showed up no game stream window, then turned them into hieroglyphs and then it signed out.

So any suggestions what this is, or should I be worried my system is compromised? It will be a solution to just format my drive, but of course I want to avoid this.

Sorry to break it to you, but your system is definitely compromised. To be truly safe you must do a complete disk wipe.

Something you can attempt is a system restore. If you have a a restore point prior to the infection you can possible be saved. Usually one is created prior to Microsoft's second Tuesday of the month update. That being said it IS possible to infect this system restore, but prior to doing a complete reformat I'd advise at least checking into this option.

It is a significant risk to retrieve files from this infected machine, those files themselves could be corrupted. Files in the "My documents" folder or on the desktop are especially suspect to being infected. If you lift files be prepared to do a second disk reformat if the problem reappears.

If you do a complete disk reformat you're 99.9% safe. There are types of persistent malware which live in the bios but they are extremely rare (or from lenovo:) ).


Browsers and HTTP Public Key Pinning The strength of HTTP Public Key Pinning (HPKP) is that the browsers are saving the keys from the HTTP header and can check in the future if the certificate from the website is valid.

I have two questions concerning that because I couldn't find a good answer:

Assume, the HTTP header says that the key pin is valid for 60 days (max-age). Where is it saved? When I delete my browser history and cache every day, is HPKP pointless then?
Assume, I am on a website that supports HPKP and the HTTP header says that the key pin is valid for 60 days. Now, when I visit the website after a week again and the HTTP header is still the same, then it's valid for 60 days once more, right?

Assume, the HTTP header says that the key pin is valid for 60 days (max-age). Where is it saved? When I delete my browser history and cache every day, is HPKP pointless then?

That will depend on the browser. There are usually several "stores" you can clean, but you should contact your browser vendor about how to do this / request a way to clean history and cookies but not key pinnings.

(Note that depending on your goal, it may be dwarfed by pinning. If you just want to avoid being fingerprinted by the company, that pinnings are kept shouldn't be an issue for now¹, but if you want to conceal that you accessed a web site, and a pinning for it is later found in your computer…)

  Assume, I am on a website that supports HPKP and the HTTP header says that the key pin is valid for 60 days. Now, when I visit the website after a week again and the HTTP header is still the same, then it's valid for 60 days once more, right?

That's right.

¹ It is possible to abuse it to expose visited sites or even work as a supercookie, though. See the slides for the Sniffly attack at
https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf


Passphrase using same word several times I used a trivial 3-letter dictionary word five times in a row (smth similar to pwdpwdpwdpwdpwd), and am surprised to find my self in the list of hacked accounts in a penetration test using a dictionary attack. I did pass the bruteforce attack though.

After reviewing the entropy of the idea of joining repeated words in a password I am no longer surprised. Here's my simple analysis as I understand it: (top part of blog entry, and sorry if it is a bit trivial, I'm trying to explain to my GF(non-math person) various aspects of IT)

Question: Is there any conceivable situation in which repeating a word in a password to reach >15 characters usefully gives more security?

Example idea:

pwd= "pneumonia" (9 char) => pwd(15)= "pneumoniapneumo" (15 char)
pwd= "cherrycake" (10 char) => pwd(19)= "cherrycakecherrycak" (19 char)
pwd= "aliens" (6 char) => pwd(15)= "aliensaliensali" (15 char)

Perhaps the concept of using a short pwd/passphrase and repeating it to some cut-off point (remember number of chars or last cut-off letter) is a viable password approach?

Your analysis is correct in this: randomness is everything. The attacker will try "potential passwords" and will be defeated only by choosing your password in a large enough set, so that the number of "potential passwords" far exceeds what the attacker may practically try with the computing power and free time available to him.

In practice, repeating the same word several times is a classic trick, which many people use because of the widespread myth that longer passwords are stronger: this is wrong, but many people nonetheless believe it. Since many people follow the repeated-word strategy, password cracking tools follow it, too.

Therefore, the best you could hope for the entropy of a repeated-word password is the sum of the entropy of the base word, and the entropy of the repeat count (or total password length)(this is a sum because I am expressing the entropy in bits, which is a logarithmic scale). For instance, if you choose the base word in a list of a bit more than 30000 possible words (which is an already quite large vocabulary, by today's standards), then that's 15 bits for the base word. If you then repeat the word to achieve any length between 12 and 27 characters, with the length being chosen randomly, then that's 4 extra bits (16 choices for the length), for a grand total of 19 bits of entropy -- i.e. not a lot of entropy after all.

An extra point to consider is that password length may leak. Not in the hash, but in other contexts:

"Shoulder surfers" may have a peek at your screen when you type the password. They will only see a collection of bullets (password entry fields are hidden), but they could see how many such bullets appear, yielding the password length.
In a similar context, people within earshot may try to work out the number of keystrokes, there again yielding the number of passwords.
In an HTTPS context (i.e. a login form of the Web), the password you type will be sent into the SSL tunnel, encapsulated in a Web form. Eavesdropper on the line will not be able to see the password (SSL does encryption) but they will be able to see the length of the HTTP request, because data length leaks from SSL (with single byte accuracy when an RC4-based cipher suite is used, as Web servers are prone to enforce in a slightly misguiding attempt at defeating the BEAST attack -- which does not work anymore, by the way).

Summary: the repeated-word strategy does not yield a lot of extra security, possibly none at all if the password length has leaked, which happens in several password usage contexts. As such, this strategy is not a good usage of the user's willingness to type a complex or long password (and that is a scarce resource).


External cross domain include script One of my web application underwent a vulnerability assessment recently, and one of the findings is about cross domain include script. Our web app uses addthis_widget.js from AddThis to bookmark Facebook/Twitter etc. It was recommended that we copy the contents of the script onto our own domain and include it from there, or re-implement the script's functionality within our own code.

Is this a really an exploitable issue?

If code is served by a large Content Delivery Network (CDN),  like Google's CDN, then it is more than likely that you will be hacked through other means.  Large CDNs have a lot of money to spend on security, and a CDN is unlikely to be a weak point in your own infrastructure.

Once a site hits a certain level of popularity, then it needs to serve static content from a CDN. Consider the following post:

Why should I use Google's CDN for jQuery?

The good from a CDN outweighs the extremely unlikely possibility of compromising a well-maintained server that is distributing static content.  That being said,  I've found a major flaw in an Akamai product...


Where can I find a collection of Threat Models? I found a very nice SSL Threat model on this web page and would like to find more on different topics.

How would I go about locating more images like these?  Is there an organisation or website I could go to?

SANS.org have a few really good resources. Including:

http://www.sans.org/windows-security/2009/07/11/practical-risk-analysis-spreadsheet/
http://software-security.sans.org/resources/paper/reading-room/threat-modeling-process-ensure-application-security
http://www.sans.org/reading_room/whitepapers/securecode/threat-modeling-process-ensure-application-security_1646

Also for web application try https://www.owasp.org/index.php/Threat_Risk_Modeling.


Possible to generate short signed strings? I need to receive emails and put them in different "inboxes". Identifying and validating an inbox involves a database hit in order to search for the to-address.
I would like to not hit the db if I know that the to-address is not valid. As of now the inbox names are generated as random strings with only smallcaps and 1-9 (email address friendly).
Would it be possible to generate signed strings so I could check them without a db-hit, much like I handle JWTs, i.e. no db-hit is necessary?
This is what I need:

random strings with only smallcaps and 0-9
preferrably about 10 char long
will need at most a couple of 100,000 unique strings

The collision risk is already handled. I'm generating new strings until they won't collide with existing strings.

edit:
I thought I'd take the golden hammer on a test-run. If I haven't done something stupid in my test, it seems like it's plenty fast.
According to the my code (node.js) below it takes about 250 nano seconds to calculate one hmac on my MackBook Pro. The roundtrip to the database for a simple lookup is of course way slower.
Even if HMAC is way overkill I like the solution, becuase I don't need to implement the following:

b-tree building and searching
notification listening from the database so I know when new inboxes are created
adding new inboxes to the b-tree upon db notification

const {createHmac} = require('crypto');
const NS_PER_SEC = 1e9;

const time = process.hrtime();

for(i=0; i< 1000; i++) {
  const hmac = createHmac('sha256', 'secret');
  hmac.update('email-address');
  hmac.digest('hex').substr(0,5);
}

const diff = process.hrtime(time);
console.log(`Benchmark took ${diff[0] * NS_PER_SEC + diff[1]} nanoseconds`);

edit again:
My first benchmark was flawed. I forgot to digest. Since digest can only be called once, I need to recreate the hmac every time.
Instead of 250 nanoseconds I'm now at about 10,000 nanoseconds. Still orders of magnitude less than a database roundtrip.

Yes, but with your requirements it is not really going to be very secure. With 10 characters and 100,000 valid values, the search space is just too small. However, since this seems only to be an optimization step, it may be acceptable.
Simply sign the value, base-36 encode the signature and truncate it. So you would call HMAC(key, inbox), convert its output to alphanumeric and take as many characters as you want.
When creating the inbox identifiers, you could take five random characters and append a signature of five characters. When validating, you recalculate the signature over the first five characters and check that against the last five characters.


Should passwords be revealed in error message? I am having pet-peeve with PHP's PDO class. As you can see on the Warning note: it reveals database password by default if an exception was not caught (when display errors is on which is a probable situation in a production server for novice webmasters).

Here's my argument with a PHP Dev

Me:

  It is quite unusual to reveal passwords since MySQL itself conceals passwords for debugging or when error occurs. For example the typical output of MySQL is "Access denied for user 'root'@'localhost' (using password: YES)" it never reveals password.

  As we know many novice programmers or end-users who uses third-party software that rely on PDO probably don't care about display_errors being turned off.

  I think this a security risk. For example, a malicious user can run a spider and search for websites with the string "Fatal error: Uncaught exception 'PDOException'" and they can now harvest passwords.

  I hope you consider this.

PHP Core Dev:

  Yes, running production server with display_errors=on and printing out backtraces with argument is a security risk. That's why you should never do it.

It appears that the PHP Core Dev would rather rely on the end-user to turn off error displays. Granting they made a warning, still it seems unacceptable given that MySQL itself (the one PDO is abstracting) is not revealing the password and yet PDO prefers to reveal it.

Do you think the PHP Core Devs are right on revealing passwords on error?

This question is loaded, but I completely agree on the answer: no, passwords should not be revealed in error messages. Passwords should never be written out anywhere without the explicit consent of the user. Consider the following roles and how they might access the wrong password that the user just typed:

The user. That's the only role who should be able to know what she just typed. Fine.
Someone shoulder-surfing. Most password entry forms obscure the password into ****; showing a password on-screen defeats this protection. This is irrelevant if the password is not shown in a production environment (but more on this below).
An administrator of the system where the password was. A rogue admin can generally obtain the password by inserting some surreptitious logging code, however this is an active attack, at risk of being detected. Even if the password is only shown in development configurations, it means the code is there and can be reactivated with an innocent-looking change of many configuration variables at once. It is common practice to hide passwords from administrators: they are not logged by any non-web general-public software that I've ever seen; system administrators and IT support staff routinely avert their eyes when a user is typing a password in their presence.
A developer of the application to whom a bug report has been made. That role never should have access to passwords. Including passwords in error traces, even if they are only shown to those who have the most use from the traces, is not good.
An attacker stealing a backup of error traces, or being able to see a backtrace du to a misconfiguration (such as accidentally setting display_errors=on).

The value of the wrong password as an asset depends on what it is. If it is a typo on the correct password, the wrong password is practically as valuable as the correct password. If the password is a password for another site (oops, I typed my production site password in the user login form on the test environment), it is practically as valuable as a credential to that site. Revealing the wrong password has high risk of disclosing a high-value asset.

The developer's response is deeply unsatisfactory:

  Yes, running production server with display_errors=on and printing out backtraces with argument is a security risk. That's why you should never do it.

First, there is a strong security concern even in a development environment, even if the logs are only ever shown to those who would legitimately see them.

Second, everything “is a security risk”, but some risks are worse than others. Backtraces can reveal confidential information that may be assets in themselves or may become one step is an attack path. That's not as bad as handing out passwords on a silver platter.

Zeroth and foremost, this response shows a very narrow view of security: “if you use my software correctly, you won't have any direct risk”. Even if that was true (it isn't), security is a holistic concern. It is difficult to ensure that every component of a larger system is used precisely as the author of that component intended. Hence components must be robust — this is also known as “defense in depth”. A rule like “never log passwords” is simpler than “don't show backtraces to those (who?) who shouldn't see them, and turn them off anyway (and if you need them, too bad)”.

There might be a difficulty in recognizing what is a password and what isn't. It can be argued that to hide passwords creates the expectation that passwords will always be hidden, which is a bad thing if they aren't. I think the rate of success is more than enough to justify doing best effort here.


How to identify and analyze malware that checks for security tools before running? I've been reading about the ZeroAccess and looking into some bot's code source* and I found this piece of code which checks if filemon is running in the infected computer before running the bot.

  int pmain3()
{
    std::vector<DWORD> SetOfPID;
    GetProcessID("filemon",SetOfPID);
    if (SetOfPID.empty())
    {
        // Nothing found running, Safe to execute bot.
    }
    else
    {
        // One of the process was found running, Exit install.

    ExitProcess(0);
    }
    return 0;
}

It's not the only one. There are others checking for Wireshark, tcpview, procmon, VM, VirtualBox, sandBox ...

In this case how can I analyze an infected computer? and how could I find the infected process?

PS: [*] taken from the IMbotMod V4.1 botnet

Malware was detecting the presence of Rootkit Revealer, so they changed the way that program ran.  It now is started by a windows service with a randomized executable name.

Similarly, you could use a supervisor process to launch procmon and any other detected executables under "assumed" names.


Securing internal micro-services - Letsencrypt vs. Self-signed certificates - Best practices Wondering if you typically use certificates from a verified CA for your internal microservices, or you just use self-signed certificates. Wondering what the typical secure setup is for this. Buying verified CA certificates seems like too much, but I'm not sure. Thank you.

Public certificate authorities generally won't work for internal services as your services are not reachable from the outside, so they have no way to verify that the certificate is being issued to the right entity. For example, if you asked Let's Encrypt for a server certificate for backend0001.myapp.myinternaldomain, Let's Encrypt needs to be able to verify that the request case from that hostname. For internal services, this is usually not reachable from the outside world.

Certificate authority:
Instead, you should have an organization-wide CA managed with the same paranoia as a real CA (you need to absolutely control access to the CA key and ensure that you only issue certificates to the right entity).

CA certificate:
The CA certificate will need to be available to all your servers and clients to be able to validate certificate chains.

Server and client certificates:
Server and client certificates can be issued to your apps and client after verification of hostname or client identity. Deployment of certificate keys is something to be very careful about. You could use something like keywhiz or vault (just some examples, there are many others) to deploy certificate keys only on the correct hosts.

The biggest complexity is making sure that keys are only available to the right parties. Getting that part right is more of a process setup and less about the technical aspects. But then again, the same problem exists with a public CA (minus the CA key issue).