Security concerns for image server? I am new to the concept of security. I have a simple image server that takes in username and an image to be uploaded. Given a username on a different URL, all images can be viewed as a slide-show on the browser. The image is stored in the S3, and the URL to the image in S3 is stored in database in RDS. I was shortlisting all security measures that need to be taken. I would like to know more points if i missed.

HTTPs connection for file encryption.
Encryption of image while uploading/downloading (is it mandatory or overkill) ?
What database security / Access controls measures are required if any ?

2)overkill unless people are uploading something like ssn's or CC's, in which case it could be useful if a proxy, vpn, malicious access point, or other service stops https

3)sql injection if SQL, other problems if not.

after uploading the file you need to make sure it gets displayed as an image


Find the person behind an email address using its recovery email in Gmail Note: This is based on a true story!

The Story:

Alice and Bob are good friends and each one knows the personal email address of the other person and they contact with each other using it. Let's assume they are bob@example.com and alice@example.com for Bob and Alice, respectively.

Bob is a member of an online community (i.e. such as a forum) and he has put another email address of him, say carol@gmail.com, on his profile so that other users can contact him using it (that online community does not have a built-in message system for the users to contact with each other). Further, Bob has setup bob@example.com as the recovery email address of carol@gmail.com. And he has not (intentionally) put any other personal information on his profile that says this account belongs to Bob.

Alice knows that Bob is a member of this online community, however she doesn't know which account belongs to Bob. She suspects that this profile with the email address carol@gmail.com on it belongs to Bob, but she is not sure of it. In order to confirm her suspicion, she comes up with this plan:

She goes to Gmail website, enter carol@gmail.com as the email address and presses Forgot password? button. Then the following message is shown:

  To get a verification code, first confirm the recovery email address you added to your account: "b********@example.com"

She enters bob@example.com and then the following message is shown:

  Please enter the verification code sent to bob@example.com ...

That's it! She finds out that the account and email address belongs to Bob. She gets very excited and sends the following message to carol@gmail.com as a result:

  Ha ha! EXPOSED!

The Question:

Well, Bob is very furious at this. He argues that he has followed all the security guidelines and he has tried hard to not expose any of his personal information and identity. Rather, he blames email provider (i.e. Gmail) and says that they should have designed the account recovery mechanism such that it protects the identity of the person behind the email address.

On the other hand, Alice, at the same time being proud of her ingenious plan, thinks that in this case there is an inevitable trade-off between convenience and security. She says that Bob has setup the recovery email so that he does not worry about his password being forgotten by him, and in turn this has the side effect of revealing his identity.

Who is right here? If you think Bob is wrong, what should have he done to both secure his identity and his email (i.e. keep it recoverable)? And if you are on Bob's side and think it is the email provider's fault, how should have they implemented the recovery mechanism?

Further, note that I am not insisting that only one of the parties is right and the blame is on the other side. It might be that both parties are wrong or right as well. If you have other viewpoints, I would be glad to hear them.

Who is right here?

Both Bob and Alice are correct.

  [Bob] blames email provider (i.e. Gmail) and says that they should have designed the account recovery mechanism such that it protects the identity of the person behind the email address.

Bob is correct that the account recovery mechanism is not designed to prevent an attacker from extracting side-channel information, e.g., guessing the email address behind the email address.  So his complaint that their system design had a flaw which allowed his identity to be revealed is true.

That being said, his assumption that they should have closed that flaw is questionable.  Gmail does not purport to provide anonymity, and that attack is not part of the threat model they've architected for.  Which leads us to...

  [Alice] thinks that in this case there is an inevitable trade-off between convenience and security.

Alice is correct that the trade-off between convenience and security explains the loophole she took advantage of.  Gmail could just as easily ask people for their recovery address without the hint; it would be harder for people to remember which address they gave Gmail when they set the 2nd account up.

Gmail architected a usable system, and it is neither designed for, nor advertised as, providing effective anonymity.  Caveat emptor.


Clarification on OAuth Client Secret I have a little trouble understanding, how to use OAuth to secure an API. So I developed a RESTful service, which I would like to secure to authenticated access. I first opted for HTTP Basic + TLS, but then decided to also support OAuth. The Jersey library supports OAuth1. After I got that working, the first consumer of that API will be a web application.

So I need to register a consumer, to obtain a client key, together with a client secret. I need these two to initiate the OAuth1 flow. Therefore the client (web application) need to have them. But that means every user of that webapp has now the client secret and key, and is able to impersonate me as a developer and luring user into phishing traps.This also applies, arguably to a lesser extend to other clients, which might first need to be disassembled. But the ultimate problem still exists.

But there must be a misunderstanding on my side, since such a problem would have surly been in the way of the wildly adoption of it.

One possibility that comes to my mind is, as a client developer, initiating OAuth only server-side. Is this the solution, or is there no such problem?

OAuth can be used in many different ways.  If an OAuth tokens is being issued to your web application using your secret key (making your web application into the 'client'),  then no one should access this token,  rather the role of your web service is to perform actions on behalf of other clients and your application must have access control in place.

Alternatively,  OAuth is also used to authenticate browsers.  So if a browser is going through a 3-legged OAuth flow, and then provides your application access to a 3rd party web resource.  Then essentially the browser owns this token,  and is letting your web service utilize this OAuth token.  The client is trusting your web service to keep this OAuth token a secret.


are organizations that receive certificates considered "end entities" in a PKI? I am trying to understand the term end-entity. Does this term just mean anybody that plays a role in a PKI system that is not a CA? So if I request a certificate from A who is a CRL issuer for Verisign then am I an end entity to verisign? Is A?

An end-entity certificate is a certificate which is not used to validate signatures on other certificates, i.e. a certificate which does not contain a CA public key (its Basic Constraints extension is absent, or contains a cA flag with value FALSE). It is called "end-entity" because it appears, necessarily, at the end of a certificate path.

A CRL issuer certificate, i.e. a certificate for some entity who signs CRL (on behalf of a CA), can be an end-entity certificate, since signing CRL does not require to be a CA.


Is YubiKey vulnerable to BadUSB exploits? I know that BadUSB (revealed by srlabs.de a number of years ago) works by altering the actually firmware of a particular make of USB device, and as such my trusted systems have their own designated USB devices which are never used elsewhere. I was thinking about buying a YubiKey to use across trusted/non-trusted systems for another factor of authentication, but I was unsure about the claim on their website:

https://www.yubico.com/faq/upgrade-yubikey-firmware/

  Yubico is dedicated to providing a long-term two-factor authentication
  solution, we want your YubiKey to remain useful for the full extent of
  its lifetime. When we do release new firmware, we ensure the new
  YubiKey will function the same as older versions, so there is no need
  to purchase new YubiKeys to ensure compatibility.

Will I be safe from BadUSB using a YubiKey across machines with varying levels of trust?

Yubico specifically addressed the problem of BadUSB in their blog post from August 2014 confirming separately capabilities of each of their products:

FIDO U2F, YubiKey Standard, YubiHSM are not capable of having their firmware upgraded;
YubiKey NEO supports firmware upgrade, but requires the new firmware image to be signed by Yubico;
neither of the devices contain memory capable of storing malware code;
YubiKey 4 released in November 2015 is not mentioned.

Yubico is aware of the problem and claims to have taken precautions against the attack (in case of devices technically capable of having firmware upgraded).
Unless Yubico breaks their promise by either a flaw or a change in the aforementioned policy, there is no way to alter the firmware in YubiKey without a physical intrusion.
The ultimate decision whether to trust Yubico as a provider is on the user.

Regarding the quoted entry from the Yubico FAQ, it's full content is:

No, It is currently not possible to upgrade YubiKey firmware. To prevent attacks on the YubiKey which might compromise its security, the YubiKey does not permit its firmware to be accessed or altered.
Yubico is dedicated to providing a long-term two-factor authentication solution, we want your YubiKey to remain useful for the full extent of its lifetime. When we do release new firmware, we ensure the new YubiKey will function the same as older versions, so there is no need to purchase new YubiKeys to ensure compatibility.

The first paragraph means YubiKey firmware is non-alterable.
The second paragraph means: when Yubico releases a YubiKey with an updated firmware version, they ensure the compatibility of the supporting software with the old devices (which are not upgradeable).
There is no room for interpretation or speculation.


Disable directory browsing using Apache htaccess file TL;DR

What are the risks and downsides associated with allowing Options -Indexes to work in arbitrary .htaccess files on a shared Apache web host?

Context

Apache web server configuration
Linux RHEL host

Background

Trevor is using a shared hosting environment where he does not have access to change the apache httpd.conf settings. As a workaround for this limitation, he attempted to use Options -Indexes in a local .htacess file in order to prevent directory browsing, as specified in this semi-related post: folder and file permission shared host advice (I refer to the accepted answer)

Problem

For this particular host, this setting returns an Apache configuration error.

It turns out the sysadmin for this particular host disabled the Options directive, so that it does not work inside .htaccess files, and that is the source of Trevor's woes.

Questions

Trevor would like to know what specific risks were intended to be minimized by not allowing Options -Indexes to work in arbitrary .htaccess files on the shared webhost? Was the sysadmin being over-paranoid, or was there really a specific attack vector closed off by this approach?
What alternative risk mitigation tasks are available, other than adding an index.html to every sub directory?

See also

Is it possible to list folder from my web server if i have an empty index.html in the root folder?

Allowing Indexes doesn't only allow disabling them, it also allows quite a bit of other options which could increase the attack surface.

Also, just setting AllowOverride to anything but None has a performance penalty as Apache now looks for .htaccess files in each directory of the requested file's path.


Google Timeline: is it encrypted and if so who has the key? Google Timeline claims (e.g. here) that "Your Timeline is private, so only you can see it."

What does that mean? As a cryptographer I would take that to mean that the Timeline data is encrypted using a key that only I have access to.

But based on some of the features, that doesn't seem likely. For instance it can be accessed from any device provided I log in to my Google account, which would make key management hard. It seems that the recommendations it sends are based on it doing some ML on the data, which would be very hard to do if it were encrypted. And it now sends an email with a customized summary of annual activity. (I don't actually have Timeline enabled; this information is based on what I've heard from friends and seen online.)

Is Google actually doing some fancy FHE or MPC thing to analyze Timeline data while it's encrypted? Is the data being processed by your local devices? Or by "only you" does Google mean "only you and Google"?

(Note: I originally asked this question at crypto.stackexchange.com and was advised to move it here. It may also be possible that only Google knows the answer to this question.)

It means they will not post it in public places, not show it on other people devices, things like that. It's like those sites who ask your email and say it will be kept private, unlike your picture and nickname that are public. It's not private on the crypto sense, more on layman's sense...

It does not mean it's encrypted in any way or form, or only you can see it (and they cannot). It's a way more relaxed definition of private.


Security measures against packet sniffing I work in a environment where packet sniffing can be easily done . I was worried about my confidential data . Please suggest how is it done and  precaution which i can take at client level.

When you feel your local computer network is insecure, there are five main approaches.

Ensure that your computer and the destination computer use encrypted network protocols. (e.g. IPSEC) This encrypts any and all traffic from your machine to the destination machine over the whole of it's journey.
Establish an encrypted tunnel between your computer and a trusted network. (e.g. VPN). This encrypts any and all traffic from your machine to any destination over the untrusted part of it's journey.
Use only applications that encrypt their communications. (e.g. HTTPS). This encrypts your communications with just that application over the whole journey.
Encrypt sensitive files before sending them over the network. (e.g. zip them with AES enabled). This only works for the very specific scenario where you are sending discrete files.
Don't use the network at all. (e.g. go home) This is safest and should be your default position. If your attackers can sniff, they may well be able to alter, and then you have to start worrying about Man-In-The-Middle.

Which to use depends on precisely what you are doing. If it's just "read my private gmail and do my online banking" then HTTPS should be enough, but if you want to hide all your private online activity then a VPN to home might be a better idea.

Lastly, bear in mind that your employer may not want you to be doing any of this. Apart from stopping you goofing of, some organisations want to read everything you send out of their network to ensure you are not leaking confidential information. So may try and block any and all of these, either by policy or with technical controls. Again, the safest method is to do your private stuff somewhere else.


Can DPI block websites with ESNI? I live in a country with censorship and was wondering if it's possible to bypass DPI by just enabling ESNI, DNS over HTTPS and Always HTTPS? If not, what else should I enable to bypass DPI firewall without having to go the VPN route?

A DPI solution cannot do targeted blocking when ESNI is used just by looking at the TLS ClientHello. But it can simply block any use of ESNI - see China is now blocking all encrypted HTTPS traffic that uses TLS 1.3 and ESNI.
Apart from that ESNI is not a thing an end user could actually enable globally. ESNI needs support both by the HTTPS server itself (or the reverse proxy in front of it, like in case of a CDN) and must also be setup in the DNS for the domain. And even with ESNI enabled and not blocked one can still monitor which IP addresses get visited, which can often be mapped to one or few domains served on this IP.

... what else should I enable to bypass DPI firewall without having to go the VPN route?

The proposed solutions don't provide adequate protection as described. There is no additional thing to enable to bypass the DPI. Instead use a VPN, HTTP proxy over HTTPS, SOCKS proxy over TLS or similar which transfers all traffic encrypted to a trusted endpoint, bypassing the DPI.


How are private keys encrypted? I've just got back into the swing of using pgp and I'm wondering how the private key is encrypted (using the passphrase to decrypt). This has got to written down somewhere, but in my searches the vast majority of answers are false positives 'How does private key crypto work?' rather than 'How is the private key encrypted by the passphrase?'

Additionally: Would it be right to say that private keys are symmetrically encrypted because it took a passphrase to encrypt it, and that same passphrase to decrypt it?

Lastly: What is the reasoning behind using a passphrase to encrypt the private key? Is it just that added layer of protection, if your private key file is compromised you are then able to revoke and reissue keys before an attacker can brute force the passphrase?

Thanks!

Key pairs are generated in a number of ways, but I am going to refer to the specific example of OpenSSL, which is a very popular and easy way of creating RSA keys for many uses.

The command for creating a key used to be[1]

openssl genrsa -cipher_name -out file_name_in_pem_format key_length

Where cipher_name can be a number of symmetric encryption methods like AES, Camellia, Des3 or IDEA.

genrsa has actually been superseded by genpkey, but the same cipher options remain.

This actually answers your follow-up question. Yes, the ciphers are symmetrical so that a single password can encrypt/decrypt the key.

Finally, yes, the password is a security measure in case your private keys fall into the wrong hands. The bad guys would have to crack one more password before being able to impersonate you or your server. It might just buy you enough time to revoke the keys.

[1] https://www.openssl.org/docs/HOWTO/keys.txt


Is a prepaid SIM-card with 3G data anonymous? Say I buy a prepaid sim-card with 3g data and put it in a used 3g modem (dongle) or a used smartphone and then create a Hotspot.

How would it technically be traced back to me? The ISP should see a Mac/IMEI of a device that isnt linked to me, and the IP is linked to an anonymous SIM-card.

Am I missing something here?

many of the large mobile (internet) providers use huge NAT to manage internet access for their customers.  I recently was doing a forensic job and was surprised to learn that some don't keep any track of their IP assignments to "handsets" against time/source port.

So if a web connected resource is trying to establish who was using an IP address associated with a 3G connected device (direct; no VPN etc) then some telecoms provider will not be able to satisfy their request simply because they don't store the information - at all.

This is interesting information for those that wish to have privacy online but what is not clear is exactly which mobile providers do this.  Also, with the 3G provider that I dealt with (through a legal team) some of their devices/customers are monitored for IP address assignment and others aren't - e.g. the prepay USB 3G dongles are monitored, but prepay handsets aren't.

good for privacy - but a bit frustrating when you're an investigator!


Is this security/encryption scheme secure? I'm rolling my own, personal threetags.com-style 'encrypted data in the cloud' webapp (I didn't like the UI, and lack of non-browser client).

However, I have absolutely no experience with security and encryption, and cobbled together this scheme after reading up on threetags' security, Wikipedia articles, and documentation for the .NET cryptography library.

Before I get to my scheme, here's a quick overview of how I understand threetags' security scheme:
They encrypt and decrypt data on the client using a key derived from the plaintext user credentials, and send only encrypted data to the server. For authentication, they use an unrelated hash of the plaintext user credentials. Since, theoretically, the credentials stored on the server used for retrieving data cannot be use to actually decrypt the data, nobody, not even the server owners and client programmers, can decrypt the data unless they get the original plaintext credentials from the user.

Assuming they have the right idea, and such a setup does guarantee safety of the data (as long as the user's password isn't compromised by a keylogger, the user doesn't save the password in plaintext form somewhere, etc.), I want to know if my implementation does the job.

The procedure I use for sending encrypted data is:

User enters a plaintext username, password and data into the client.
User registers or logs into the server by sending SHA-256 hashes of the plaintext username and password. Each hash is salted* with a 5-byte salt.
Client compresses the data with gzip, then encrypts it using AES-256; the 256-bit (256/8 bytes) key is derived from the plaintext password using PBKDF2 with an 8-byte salt* and exactly 11368 rounds. The IV is automatically generated by the library class, and I append it unencrypted to the encrypted data for later retrieval.
Encrypted data is encoded as a Base 64 string and sent to the server over HTTP, because who needs HTTPS if the data's already encrypted as can be?
Client is free to retrieve the Base 64 data, decode it, decrypt it, decompress it, and have it back in its original plaintext form - so long as they can provide the plaintext password for the decryption key.

*For an N-byte salt, I take the unsalted SHA-512 hash of the plaintext I want to salt (or the plaintext I want to feed to the algorithm that takes a salt), and pick a deterministic subset of N bytes from it (say, for a 3 byte salt, the 1st, 3rd and 5th bytes of the unsalted hash - is simpler better for this?) - that sequence of bytes is my salt.

If it matters, I'm using .NET Framework 4, System.Security.Cryptography classes. I programatically specified the number of rounds only for their PBKDF2 implementation, since that's the only case where I saw an obvious property/method to set it with. I suppose that level of detail is a thing for Stack Overflow though.

In any case, I'm more concerned about absolute, conceptual security than speedy computing, but I'll gladly take any suggestions for improved efficiency (if anything I do is redundant), as well.

"I have absolutely no experience with security and encryption": Yikes.  It is probably not the best idea to be designing new cryptographic schemes, given this sentence, if security is important for your application.  Cryptosystem design is a tricky subject.  Folks who try to invent their own schemes without knowledge of the field often make non-obvious mistakes.  If I can use an analogy, I wouldn't try to perform surgery on myself; I'd go to a qualified surgeon.  If security is important, you should do the same.
On your particular scheme: It definitely has some positive aspects, but it also has some significant shortcomings that I spotted (with no guarantees that this list is exhaustive):

Rolls its own crypto. As a very general comment, the number-one lesson from the history of cryptography is that rolling your own crypto is highly error-prone.  This is particularly a risk factor if you haven't studied the area deeply.  Therefore, you are skating on thin ice, and you should expect that your scheme will likely have security problems that you didn't anticipate.

Leaks the password. User passwords tend have little entropy.  Therefore, it is critical to reduce or eliminate opportunities for offline dictionary search against the password.  Using PBKDF2 is a good idea, but you then shoot yourself in the foot by sending a (plain) hash of the password to the server.  That enables rapid offline dictionary search.  And there is no need for it.  You shouldn't send a password hash to the server.  For instance, it would suffice to send only the username to the server (and not anything derived from the password).

Insufficient iterations of PBKDF2 to protect the password. In addition, I suspect that 11368 iterations of PBKDF2 is not enough to prevent dictionary search attacks.  Best practice is to select a number that is large enough to make the operation take, say, 1 second.  See, e.g., this question on IT Security.

Insecure salting. The scheme you use for generating the salt is totally broken.  You are using a deterministic function of the password as the salt; this totally defeats the purpose of a salt.  The salt should be a crypto-strength random value, say 64 bits in length or more.

Doesn't authenticate data. You encrypt the data, but you don't authenticate it.  Without authentication, attackers can tamper with the data, and you won't be able to detect it.  Also, for subtle reasons, encryption without authentication is insecure.
Fix: After encrypting, you should compute a MAC on the ciphertext using a strong message authentication code (e.g., AES-CMAC) and append the MAC.  Before decrypting, you should check the MAC.  Don't use the same key for encryption and for the MAC; when you derive keys from the password, you should derive two independent keys (256 bits).

Doesn't use HTTPS. I'd recommend using HTTPS.  Encryption and authentication only defend against some threats.  For instance, they don't ensure that you get the latest version of the data.  This means that, in your scheme, if a client is connected to the Internet over an open wireless connection (for instance), a man-in-the-middle attacker might mount replay attacks that replay old versions of the data.  I suggest that you connect to the server by HTTPS.

May be susceptible to traffic analysis.  Encryption does not conceal the length of the data being encrypted.  Also, when compressing data, the length of the compressed data can potentially reveal some information about the data itself being compressed (not just its length), which may pose additional risks.  These risks might be acceptable or unavoidable, but you'll need to analyze them in the context of your particular application and the types of data typically being stored.

Even if you fix all of these problems, there is no guarantee that the result will be adequately secure.  Generally speaking, if initial review of a design indicates 4 problems, even if you fix the problems you know of, one should be very suspicious: how do you know there isn't a 5th problem that you just missed?
That said, there are also a number of positive elements in your design.  For instance, you are using standard well-vetted algorithms, which is good.  Overall, I think you're on a reasonable path -- there are just some non-obvious issues you probably haven't anticipated.


envelope encryption (using KMS) vs ECDH at work I have implemented basic envelope encryption when sending messages to a client.
I am using AWS KMS and have a master key there.
I get a data key, encrypt the message with AES-GCM and send the message with the encrypted data key, IV, tag etc. The client then calls AWS KMS to decrypt the data key to decrypt the message. I have implemented this looking at the AWS docs. I am caching the data key for a while for reuse before generating a new one.

One colleague, that is better at cryptography than me, thinks this is unsafe due to sending the key with the message, that this might lead to figuring out the master key? He recommends ECDH which has better key distribution, using a shared secret with private/public keys to generate the AES key. The problem with this I feel is that I need to store public/private key pair somewhere, and both of these methods needs access to a secret (KMS key or private key).

I am looking for other opinions on how secure these different methods are. What are the difference really in vulnerability?

Edit:
Clarification: The master key is a specific key created only for encrypting data keys for these messages to one specific client, nothing else.
Docs from AWS that I used: https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping

Mathematically, you are correct that if your data key is properly generated using a cryptographically secure pseudorandom number generator, the master key can’t be reversed from a message (assuming AES is unbroken.) But operationally speaking, this scheme provides a “crib” to an attacker trying to guess the master key. It enables a “known plaintext” attack.

Consider the case where an adversary believes he has part of your master key. He can use any intercepted message from this system as a test to see if his guesses are correct. Or he can unwind the algorithm, should such an attack against AES ever become known.

This scheme isn’t following the principle of “a key should be used for a single purpose.” Because the master key still lives in each message, each data key is now sharing your master key with all other keys.

That said, I’m not familiar enough with AWS’s KMS to know how your system is configured, but all the KMS systems I work with perform key management by granting permission to individual users to access only their application’s keys. No user would ever have access to use the system’s actual master key to directly encrypt a data key. So it’s possible that your description isn’t complete, and what you have been referring to as a master key could simply be referring to an application-specific key. In that case, the leak of your key won’t lead to the leak of the other keys in your KMS. Your organization’s other keys wouldn’t be compromised even if your key was.

Even in that case I’d still consider taking your colleague’s advice and changing to use an asymmetric key solution like the one he described for exchanging keys, instead of encrypting the data keys directly with the master key. You can still have the sender and recipient use the KMS to decrypt the private keys, because the private keys are never sent with the messages. It removes the known plaintext attack against the master key.


Worst-case scenario for ShellExecute(0,"open",arbitrary_string) I found an application that uses ShellExecute to open hyperlinks. However, it doesn't check if the string is actually a hyperlink - it is passed directly to ShellExecute.

Aside from opening arbitrary URLs (incl. custom registered application protocols, which can be used to exploit vulnerabilities in them), this allows opening any file on the filesystem given its absolute path. I don't think it's possible to launch programs with custom parameters directly.

Aside from relying on vulnerabilties in other apps' custom protocol handling, what's the worst-case scenario of such a vulnerability?

There are a variety of things you could do with this issue:

Set up a shared directory on the network, put an executable on it, then send the path to that share.
Open the user's browser to a page containing browser exploits, by passing the URL.
Launch a game in order to generate a temporary DoS whilst it loads.
Launch a maintenance script for a known-installed application in order to damage or destroy data.
Launch a network service that's available on the system, then use that to gain further access.


Does client have to send the CA chain along with the client certificate after ServerHello? During the MTLS handshake, after ServerHello is done client sends the client certificate back to the server, I need to know if the client should only send the  client certificate or is it required to send the client cert along with the entire CA chain?
I have a situation where I am seeing a handshake failure post CertificateVerify. The client cert looks good and it is signed out of subCA which is signed out of a RootCA that the server also trusts (server only trusts root CA, not the subCA). In this situation, we see the client only sending back the client cert without the chain. Is that why I see the handshake failure?
I am wondering if the client sent the entire CA chain back, the server would have to know that the client is signed by SubCA which is then signed by a root CA that it trusts. I have googled and found a lot of information around server sending cert with CA chain and acceptable CAs to the client, but not anything around what the client should do.

You are responsible for sending enough of the chain for the server to connect your certificate to a trusted root.

For TLS 1.2 this is discussed in RFC 5246.  Client certificates are defined in §7.4.6, which (among other things) states:

  Client certificates are sent using the Certificate structure defined
  in Section 7.4.2.

And if you look in §7.4.2 it describes the Certificate structure as including the certificate_list (emphasis mine):

  This is a sequence (chain) of certificates.  The sender's certificate
  MUST come first in the list.  Each following certificate MUST directly
  certify the one preceding it.  Because certificate validation requires
  that root keys be distributed independently, the self-signed
  certificate that specifies the root certificate authority MAY be
  omitted from the chain, under the assumption that the remote end must
  already possess it in order to validate it in any case.

In short, the server is expected to have the trusted root, but not required or expected to have any intermediate certificates that may be required.  The client is required to provide them if it wants verification to proceed smoothly and reliably.  (And the same is true for the certificates the server sends to the client).


Can anyone determine what kind of encryption this is? Here are some examples of the encryption:

J01A062YLMP1
J01A06OEPMP1
J08A07GSVMP1
J08A0625YMP1
K01A06IE2MP1
K01A06GRKMP1
W08A06ZTYMP1

I know the first letter corresponds to a brand, the last 3 characters never change MP1, and there is always an A as the 4th character. Any suggestions on what type of encryption this is?

Judging by the structured format, I would say this is not encryption of any kind, but encoding. A possible scheme could be as follows;

brand | year | divider | month | id   | postfix
------|------|---------|-------|------|--------
J     | 01   | A       | 06    | 2YL  | MP1
J     | 01   | A       | 06    | OEP  | MP1
J     | 08   | A       | 07    | GSV  | MP1
J     | 08   | A       | 06    | 25Y  | MP1
K     | 01   | A       | 06    | IE2  | MP1
K     | 01   | A       | 06    | GRK  | MP1
W     | 08   | A       | 06    | ZTY  | MP1

The problem with encoding is you need a lookup table to figure out what any of it means. I would guess that these are keys to a database, and without that database you have no way of knowing what records these keys map to.


Performing a simpler ssl handshake Consider the following scenario:

client sends hello
server send a hello and its certificate
client generates a key and encrypts that with server's public key
server decrypts the key with its private key

So, they shared a key and can talk with each other.
What is the problem with this? Why does SSL require that the client and server both generate a random for the session?

You've just described RSA key exchange, which was used in the past. These days, (EC)DHE is much more commonly used. The main reason is that (EC)DHE has the added benefit of providing forward secrecy. This basically means that if the private key is compromised at some later date, it will not compromise the security of previous communications. This is not achievable with the RSA key exchange method you describe.
See this question for more details on the advantages and disadvantages of using DHE or RSA


Uploading zipped up virus Lets say that I have a badly-made file upload on a website. Someone uploads a zip file which contains a virus. Why would they do this? Surely the zip file is useless unless it is opened and the contents are executed?

Your assumption is correct. Why this happened? You can only speculate. Might not be a purposeful action at all. Maybe a malicious person hopes someone does exactly what you describe. The zip might have a name that motivates someone to do so like "your-bosses-private-emails.zip" or sth like this.


Using emoticons in passwords I'm coming up with a password to use for my banking website, XKCD style.

Furthermore, I'm considering adding in an emoticon (say, a <3)

How many bits of entropy does an emoticon add to my password?

You can only really calculate entropy assuming it's a randomly generated password, according to some scheme.  So if you randomly take an emoticon from a list of about 256 emoticons (256 = 2^8) and flip a coin to add this to the beginning or end of your password (2=2^1 choices), that adds 9 bits of entropy.  Remember, when things are chosen uniformly, entropy in bits is simply the base-2 logarithm of the number of possible choices.

Please note you should avoid using emoticons with non-ASCII letters in your passwords (emoticons like: ಠ_ಠ or :っ) ) as they'll often be difficult to type on different devices, may possibly be silently stripped out of the password (so add no extra strength) to avoid potential encoding and unicode equivalence issues.


What can be accomplished with a site that is vulnerable to both XSS and SQLi A comment on another question stated (quite simply):

  There are ways in which XSS and SQLi can be used together.

This one is new to me, and I'm curious to hear what additional attack vectors might open up on a website that is doubly vulnerable to both of these attacks. The only use case I can think of is if the SQLi vulnerability is present on pages that can only be accessed by authorized users: in that case the XSS might get you the privileges you need to make SQLi happen. However, it is probably going to be impossible to find such a vulnerability without being authenticated yourself (in which case you don't need XSS), so I don't imagine that is the scenario the original commenter had in mind.

Any other thoughts on how these two might build off of eachother and accomplish something together that might not be possible for one of these vulnerabilities individually?

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

SQLi via XSS

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

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

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

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

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

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

XSS via SQLi

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

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


First you need to decode all the HTML/XML entities like &#45; etc. Once you've done this you get something like this:

-----BEGIN CERTIFICATE-----
MIIGsjCCBZqgAwIBAgIQCTaYT9gNC0RFj3x3zaPxZDANBgkqhkiG9w0BAQsFADBw
...
-----END CERTIFICATE-----

  which domain(s) it is valid for?

Then you could use openssl x509 -in yourfile -text which gives you the details of the certificate including the domains this certificate is for:

...
Subject: C=US, ST=NY, L=New York, O=Stack Exchange, Inc., CN=*.stackexchange.com
Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA

...
X509v3 Subject Alternative Name:
  DNS:*.stackexchange.com, DNS:stackexchange.com, DNS:stackoverflow.com,
  DNS:*.stackoverflow.com, DNS:stackauth.com, DNS:sstatic.net,
  DNS:*.sstatic.net, DNS:serverfault.com, DNS:*.serverfault.com,
  DNS:superuser.com, DNS:*.superuser.com, DNS:stackapps.com,
  DNS:openid.stackauth.com, DNS:*.meta.stackexchange.com,
  DNS:meta.stackexchange.com, DNS:mathoverflow.net, DNS:*.mathoverflow.net,
  DNS:askubuntu.com, DNS:*.askubuntu.com, DNS:stacksnippets.net

  if this certificate is trusted

To check if this certificate is trusted you need to have the trust store you want to check against. And you probably need to get any intermediate certificates. Once you have this see the detailed description in Use openssl to individually verify components of a certificate chain.


Is there any way to bypass sni-based https filtering? From the side of the website owner, not the client.

South Korean government announced that they will censor internet by sni filtering.

According to korean law, every porn website will be blocked forever in korea.

Until now, we have bypassed censorship by connecting with the https protocol. But now it is useless. All Korean men consider this very serious.

I will surely find a way and inform it with all Korean online communities. For the freedom of all Koreans.

I have heard that TLS 1.3 does not yet support sni encryption.

So, is there any solution that can solve this problem in this moment?

There are ways to do things like using proxy, VPN, tor, but I do not think it's a fundamental solution. It is not a fundamental solution unless taking action on the server.

Connecting to a site using Tor, a VPN or even a proxy is the standard way of bypassing a network filter. I don't know why you don't consider it a solution, or why you want a solution on the server (which would probably have little incentive for implementing bypassing features).

A way to conceal the website you are connecting to by TLS is to connect requesting a domain in the TLS layer (SNI) but a different one in the HTTP layer (you would need a non-standard software for this), a technique called domain fronting.

Since the network inspection can only see the outer one, you may be able to provide an innocuous domain in SNI and have the server reply to the HTTP one. If both domains are hosted at the same IP address (eg. they are at a CDN), as the censoring agent can't tell apart accesses to the innocuous domain and the unwanted one, they would have to also block the other one. Signal used to do this, hiding their connections with TLS stating they were to google.com, a website too big to block.


What Trusted Execution Environment (TEE) solutions exist for mobile devices? A trusted execution environment (TEE) provides a way for one to deploy tamper-proof programs on a device. The most prominent example of TEEs seem to be Intel SGX for PCs.

What I wonder is, if there exists an equivalent solution for mobile devices. For example, I want to deploy an arbitrary application on a smartphone that even a malicious OS can't tamper with. Is there such a solution at the moment?

At least for ARM-based CPUs, there's TrustZone. While not the same, it is possible "SGX-like" instructions and capabilities will carry over in the future.

  Each of the physical processor cores in these designs provides two
  virtual cores, one considered Non-secure and the other Secure, and a
  mechanism to robustly context switch between them, known as monitor
  mode. The value of the NS bit sent on the main system bus is
  indirectly derived from the identity of the virtual core that
  performed the instruction or data access. This enables trivial
  integration of the virtual processors into the system security
  mechanism; the Non-secure virtual processor can only access Non-secure
  system resources, but the Secure virtual processor can see all
  resources.

http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-GENC-009492C_trustzone_security_whitepaper.pdf

https://en.wikipedia.org/wiki/TrustZone#Security_extensions


PHP - Is it safe to file_put_content raw HTML? I'm planning to create a website to let people edit/customize their stories.

Let's say the stories will store a lot of html tags ( paragraph, images & video  )

I'm thinking using some javascript plugins to let user edit their html, upload images & etc.

After user finish editing the html / customize their stories
My PHP code will file_put_contents to directory as stories-un1qu3-123.html
While file_put_contents, my php code will strip <script> tag, and onload,onclick,etc on the html that POST to server.
When other public user view the stories, my system will
file_get_contents of the html.

May I know this approach is it safe?

I wanted to save as .html it's because I'm trying to avoid query on database and straight away load the .html, may be this will be faster on previewing the stories.

I'd some research on is it only way to store the stories(HTML), is to :

separate the html tags / paragraph / images into JSON format
then POST to backend > sanitize > strip all tag > send to database
when public user view, need to connect database > retrieve the JSON text > then convert/render it to readable html format?

Thanks!

May I know this approach is it safe?

No, this is not safe as you're trying to strip tags. Rather than using a black list I recommend you'd use a white list approach. The white list defines which HTML tags users are allowed to use.

By only stripping <script> tags and the javascript on-events is not sufficient.

What will happen if I enter the following payload:

<scr<script>ipt>alalertert('xss')</scr</script>ipt>

Your code will detect the <script>, alert and </script> tags in my payload and remove it. The result will be (XSS):

<script>alert('xss')</script> and this will "pop".

Try not to reinvent the wheel here. I'm sure there are relatively safe scripts on the internet that can do this as you're not the first person to use functionalities like this. Have a look at http://htmlpurifier.org/ to get some idea's.

In addition, I'd recommend looking in to a secure PHP framework as a basis for your application to avoid other common security problems such as SQL injection and Cross Site Request Forgery.


Why is malware not commonly written in Haskell? I recently started learning Haskell, and have been reading about many of the advantages it is supposed to offer over traditional imperative programming. I came across this post about reverse-engineering compiled Haskell code, and it made me wonder about malware written in Haskell.

Are there known instances of malware written in Haskell? (Quick Googling did not turn up any results for me.)
Does the complex nature of compiled Haskell programs make it an attractive choice as a malware development language?

My assumption is that the barriers of entry to learning Haskell are too high for rudimentary malware, and that those with the time/ability to learn it are writing more complex malware that requires the low-level features of a language like C. Is this known to be the case?

[Disclaimer: not my area of expertise]

Yeah, I would assume that haskell is too high-level.

Things malware wants to, in order of priority: accomplish your task, fool anti-virus scanners on the target, resist reverse engineering and analysis in a lab.

The complex nature of compiled Haskell probably helps with the third, but probably makes the first two harder. For example, the following are common malware tasks that are probably difficult to accomplish in Haskell:

insert itself into another application or document such that it is still executable (virus behaviour)
obfuscate / encrypt its own string constants to avoid easy scanning of the binary
re-write its own code dynamically to change its fingerprint and fool anti-viruses
other evasion techniques
use and manipulate dlls it finds on the target machine
read / modify memory belonging to other processes
read / modify system data such as the master boot record

If you're at the level of sophistication where you're worried about reverse-engineering, I can't imagine that any compiled language is very attractive - you probably spend at least half your time working directly with assembly.


Are server nonce and client nonce in SSL equal? The explanation in the book is not clear that whether they are equal or not.
My thought is below.

If they are equal, the server can not prevent replay attack because the nonce is determined by the client.

If they are not equal, then it seems that the server and client must compute Master secret twice, one with client nonce and one with server nonce

What is the exact implementation of SSL?

The nonces on the server and client side are created independently from each other. This means they are most likely not the same.

  If they are not equal, then it seems that the server and client must compute Master secret twice, one with client nonce and one with server nonce

The master secret is computed by including both nonces since both nonces are known on both sides, one because it was created locally and the other one because it was received by the peer. For the details see TLS 1.2 section 8.1 Computing the Master Secret:

  master_secret = PRF(pre_master_secret, "master secret",
                      ClientHello.random + ServerHello.random)
                      [0..47];

ClientHello.random and ServerHello.random are what is called nonces in the document you refer to.


Violation of security principles? It's clear that keyless entry fobs, smart entry cards, NFC, etc. are vulnerable to relay attacks.

Suppose they were improved by limiting the period of activity, eg let them be active only when they are shaken, only when sound is detected, only when today is Tuesday, etc. These reduce the window of opportunity for attacks to occur.

Do these improvements violate any security principle? Specifically, could such improvements be conceived to be futile defences?

What you are describing is multi-factor authentication, the first factor being the proximity of the 2 devices. Therefore it does not violate established principles, but rather is becoming standard practice rather than as a response to a high profile attack. The devices involved need to know that the communication is being performed when only the user wants it to be, and that they are indeed the devices they say they are. This is achieved through secure protocols and methods to detect legitimate user interaction.

Proximity can be faked on some devices with improperly designed protocols through relay, the most public being those on keyfobs (signal amplification) and garage door openers (jam/steal 2 and replay 1st, storing 2nd for later).

Adding a second factor is not difficult, it is usually a matter of cost. The jam/steal attacks jam the signal from the transmitter to the device while making a copy, twice, then sends the first signal to the device activating it. The second copy is then used to activate the device under the attacker's control. This bypasses both rolling code transmitters and those with cryptographically enhanced incrementing counters. A synchronized time code on both devices and as part of the code generally defeats this attack. Synchronizing a timecode and keeping it that way requires high accuracy (and expensive) clocks on both devices, more power, and additional user effort.

A time code however does not usually help with a signal amplification attack. A better way to detect the proximity helps, such as an accurate measurement of the time it takes to process the device handshake, in order to estimate the distance. An excessive response time may indicate an active attack. My father's 20 year old Mercedes Benz had an IR transmitter on the keyfob in addition to RF, so the car could make sure they keyfob was pointed towards it and not being pressed in a pocket by accident. It also unlocked the specific door (or trunk) at which it was pointed, to prevent someone from sneaking into the car through one of the other doors. This also prevented RF only relay attacks, increasing an attackers equipment cost and effort.

Additional methods to detect legitimate user interaction include time-fencing (as you suggested), geo-fencing, hand detection (using capacitive touch), gesture sensing, temperature sensing (to detect attacks that modify speed of clocks and processors)

A more optimal device protocol would include cryptographically authenticated handshakes with large keys, timecodes, counters, and receipt response of messages. This type of protocol uses large amounts of power for an embedded device, so better power efficiency and higher capacity batteries are required before something like this can be adopted on a large scale. Implementing it on a phone is easy, but not so on ultra low-power devices (BTLE, IOT, smartcards, etc). At least not at the moment, but efficiency is constantly increasing.

The cost of implementation must be weighted against the effort of a successful attack during the lifetime of the device, and against the possible costs from such an attack, in the form of bad PR, lawsuits, etc.

I failed to keep this short and went a little off topic, hopefully all the information should be relevant to the question.

Here is a basic protocol I use for IRC services control, it is short and simple, and can be applied to many use scenarios.

A: Hello B, I am A, I would like you to do X

A: B + A + H_1 + X + T_A + C_A + MAC_A(msg)

B: Hello A, you are authorized for X

B: A + B + H_2 + X + T_B + C_B + MAC_B(msg + Z_A)

A: Thanks B, please do X now, over

A: B + A + H_3 + X + T_A + C_A + MAC_A(msg + Z_B)

B: Ok A, I will do X now, over and out

B: A + B + H_4 + X + T_B + C_B + MAC_B(msg + Z_A)

Where A and B are serial numbers or device identifiers, C_x is an incrementing counter specific to device x, T_x is the current timecode of device x, H_x is an identifier for part x of the handshake, and Z_x is the last MAC response of device x. The messages are encrypted and authenticated with large preshared keys, but for something like a keyfob or garage door opener only the authentication is necessary.


IP address spoofing on internet On a local network, an attacker can craft a custom IP packet with a fake source IP address and send it to a host. I know that the attacker will not receive a response, but there are still attacks for which faking/spoofing the source IP in IP packets can be useful.

But how can this be done on the internet (faking public IP addresses)? If I want so send an IP packet with a fake public source IP address, and I'm sitting behind a router that is performing NAT, I assume the router will change the fake source IP in the IP packet to the real public IP of the router. I didn't find any options to switch off NAT for particular addresses on my router. Are there routers that have such options, or is that done somehow else? Has anyone of you done something like this before?

I know that there is a similar question/answer about what happens to a packet with faked source IP that goes through NAT, but it does not really answer my question. It explains the possible problem with NAT that I mentioned, but not how to avoid the problem.

Spoofing the source IP from your home Internet connection

Remove the NAT...

If your Internet connection works like most do (any ADSL or Cable connection that I've seen so far), then there is an easy way to remove the NAT at your end:

remove the router and replace it with a modem, or just remove the router if the modem is a separate box. Some (most) routers even allow to operate like a modem; In that case you just have to switch that in software and not actually replace the hardware.
directly connect your computer to the modem
setup the connection to your ISP on your computer. Most likely this will be a PPPoE connection with some kind of username/password that you got from your ISP.
Your computer is now directly connected to the Internet, without a NAT, or any kind of firewall except of any software on your computer and whatever the ISP has in place.

...or let the router do the spoofing for you

There are also routers which could do the IP spoofing for you. Any device that runs iptables and lets you configure the rules should do. OpenWRT capable devices come to mind here.

Some problems you are more or less likely to run into

Even if you don't have any NAT at your end of the connection, the ISP may still have a NAT that you have to go through. Also the ISP may filter out packets coming from your computer that do not have the source IP they assigned to you.

Have I done something like this before?

Yes, I have done something like this on a multihomed server (so I was substituting one of my IPs for the other) and it didn't work because of the filtering described above.


What is "-srvcert" in OpenSSL cmp command line? I use the following command to get a signed certificate from PKI.

What is the content of the file srvcert.crt of the option -srvcert ?
It seems the srvcert.crt file is not the public certificate of the pki_server. Indeed, I tried with it and it does not work.

openssl cmp -cmd ir -server pki_server:8040 \
-path signing-cmp/test -cert /tmp/mycert.crt \
-key /tmp/mycert.key -newkey /tmp/new.key \
-subject '/C=FR/CN=domain.com/ST=London/L=London/O=Organization/OU=IT Administration' \
-certout /tmp/new.crt -srvcert /tmp/srvcert.crt

Here is how got the public certificate of the PKI. The option -srvcert does not work with this file.

echo -n | openssl s_client -showcerts -connect pki_server:443 \
    2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/srvcert.crt

I am citing from man openssl-cmp

  Server authentication options

  ...
  -srvcert filename
      The specific CMP server certificate to use and directly trust (even if it is expired) when verifying signature-based protection of CMP response messages. May be set alternatively to the -trusted option if the certificate is available and only this one shall be accepted.

So this option is used to authenticate the server but is not required.

The  example for enrollment in this man page does have a shared secret between server and client but does not use -srvcert at all.

openssl cmp -cmd ir -server 127.0.0.1:8080 -path pkix/ \
   -ref 1234 -secret pass:1234-5678-1234-5678 \
   -recipient "/CN=CMPserver" \
   -newkey cl_key.pem -subject "/CN=MyName" \
   -cacertsout capubs.pem -certout cl_cert.pem

My suggestion for now would be to omit server authentication and test if everything else works.


How does server validate that self-signed certificate came from the client who self-signed the certificate in mutual TLS? I have a mTLS (client authentication) setup where client sends a self-signed certificate. This self-signed certificate is transferred to and trusted by the server. The server's certificate is signed by Let's encrypt and Let's encrypt CA is trusted by the client.

[ client.key ] --
                | (signed)
[ client.crt ] <-
                                                         (trusts clients.crt)

 |--------------|               client.crt                  |------------|
 |    Client    |       --------------------------->        |   Server   |
 |--------------|                                           |------------|

How is authenticity of a client is checked when the Server receives client.crt? In other words, how does a Server know client.crt is indeed came from the Client who self-signed it?

My understanding with client.crt is that its a Public Key Certificate and because it's "public", there's no security harm if it's stolen by any other parties. Is this an incorrect assumption?

It seems odd that a "public" certificate should be treated like a secret because it's self-signed and used for client authentication.

My guess is that when a Server receives client.crt, it would encrypt some message using client's public key included in the client.crt and have the client decrypts it. Authentic client would be able to since it owns a private key associated with the public key where as malicious client with just the client.crt wouldn't because it doesn't have the private key.

Thanks in advance!

The client certificate is public, just like the server certificate. The only reason to keep the client certificate would be privacy, if you don't want to reveal that you are this particular client. Publishing the client certificate does not allow anyone to impersonate you.

Client authentication does not only require the client to show that it knows the certificate. The client shows the certificate to identify itself, i.e. to claim “this is who I am”. Showing the certificate is not authentication: for authentication, the client needs to prove “this is who I am”.

The client can prove who it is because it knows the private key associated with the public key contained in the certificate. It proves that it knows the private key by making a signature of data that includes a unique challenge sent by the server. (The challenge is some random bytes sent at the very beginning of the TLS handshake.) Including a unique challenge prevents against replay attacks: if an eavesdropper records the client's responses, they won't be able to replay them to make a valid connection to the server, because next time the server's challenge will be different.

In order to decide whether the client is acceptable, the server does two things:

The server checks that the certificate is acceptable. It may have a list of acceptable certificates (this works for self-signed certificates), or it may only accept certificates that have been signed by a particular entity. This shows that if the client is who it claims to be, it's acceptable.
The server checks that the signature from the client is correct, using the public key contained in the certificate. This shows that the client is who it claims to be.

All of these mechanisms are similar in principle to how a client authenticates a server, although the protocol is not perfectly symmetric.

Having the sever encrypt a challenge with the client's public key, and the client prove that it knows the private key by decrypting this challenge, would also work, from a security point of view. It is not done for several reasons:

It would require the client's private key to be capable of doing encryption. The types of private keys commonly used for TLS are RSA keys, which can do both signature and encryption, and ECDSA keys, which can only do signature.
It would involve asymmetric decryption. Assymetric decryption is considerably harder to implement securely than signature, because it involves both the private key and externally-supplied data (the thing to decrypt) in the same operation. There is a very long history of vulnerabilities in RSA decryption. The history of RSA signature is a lot less depressing.
It would make the protocol less efficient: it would need an extra round trip. The server can send a challenge to sign at the beginning of the connection. If it had to send a challenge to decrypt, it would first need to know the client's public key. Before the client could send its public key, it needs to know what cryptographic algorithms the server support and whether the server wants client authentication. The client sends both its certificate and its signature in the second flight of messages that it sends to the server, when it knows what algorithms the server supports. If the protocol used decryption instead of signature, the client would have to send its certificate in the second flight and there would have to be a third flight for the decrypted challenge.


static vs dynamic vs challenge response I am taking a security class. The slides say that smartcards usually use one of three types of authentication protocols: static, dynamic and challenge response. What is the difference between these?

Warning: the terminology is a bit fuzzy, so there cannot be a completely authoritative and clear-cut answer.

A static authentication protocol means that the device which does the authentication does not compute anything. If embeds some secret value but can, at best, show it. The human user, when he types his password in a login page or interface, is a static authentication device. The smallest, dumbest, cheapest kind of smartcard does the same: after having been duly unlocked (users typed his PIN code), the card spouts a secret value always the same.

A dynamic authentication protocol is the opposite: the device computes things. There are many types and sub-types of dynamic authentication protocols:

The protocol can be a challenge-response: the system which runs the authentication submits a challenge, e.g. a random sequence of bytes, to which the device responds by computing a cryptographic function which uses both the challenge and a secret data contained in the device. The cryptographic function can be, for instance, a MAC which the device computes over the challenge, with the secret as key; the authenticating system will verify that MAC (this scenario assumes that the secret value is known to both the smartcard and the authenticating system). Another kind of challenge-response is based on digital signatures: this requires heavier computations (hence a less cheap smart card) but means that the authenticating server needs not know the secret value which is embedded in the smart card.
Some cards generate one-time passwords. This can be viewed as a challenge-response protocol in which the challenge is not sent by the server, but is a publicly known everchanging value (e.g. a counter, as in HOTP, or the current time, as in TOTP). RSA SecurID tokens are of that type. Devices which use that kind of protocol must maintain some permanent state which resists resets (e.g. a battery-powered internal clock, or a counter value stored in EEPROM); but they are easier to integrate into existing systems (as with RSA SecurID tokens, the user just has to type what is displayed on his token; he does not have to plug the token in his desktop machine).


Decoding injected PHP malicious code in my server I've found on internet similar issues, and I compared the code. This one is different.

I recently found out that the CentOS LAMP webserver we use for development in our office was infected by a piece of PHP code injected at the beginning of all our .php files.

I'm putting the code on Gist/Github, because it's long, but I'm describing it and what I did here below.

https://gist.github.com/Zorgatone/5e4f72d250f11cf7ba0a

I'm trying to de-obfuscate the sourcecode to understand the damage, and see what the malicious script actually does.
I was able to decode some HEX-escaped text, but there is a part which is more complicated.

I renamed all the variables, and there is an encoded string in a variable called $foo, which is decoded by a function called mistery_f, with an ausiliary array containing a long list of numbers (variable $bar_arr).

Then there is even a piece of text in a string, containing two obfuscated "weird" comments, an eval(), a str_replace and a call to the mistery_f() function.

But I don't get the last part, seems to me this string is never evaluated to execude the code, and in the last part there are possibly some junk variables doing some arithmetics and being then ignored.

Maybe some code is missing and wasn't injected.

A lot of our websites use WordPress, that may be part of the issue.
Possibly something related to some text posted and saved on the MySQL database, in a field that wasn't large enough and truncated part of the malicious code?

I'll try to see and get some logs, if there still are any, to see how the server was exploited/penetrated.

I'm asking not because it's a production test. Fortunately it would just affect (probably) ie browsers, but we cannot make the client preview websites on this server.

I fear that could be a part I didn't notice, and maybe a buffer overflow, or something that would harm the rest of the server.

Also I'm trying to figure out why I was infected and how to protect the data of our website under development.

Any help is welcome. Thanks

This code loads content from a remote server and injects it into your website, but not when the useragent is a searchengine bot or specific $_SERVER variables are not set.

Related question on SO:
https://stackoverflow.com/a/29433260/753676

And some more details: http://www.lowendtalk.com/discussion/52704/php-code-injection-xetqlznzyr

This seems to be the final payload which can load additional payloads from the C&C server: http://pastebin.com/Z03USpr7
http://pastebin.com/1CjSMvbz

Also related: https://magento.stackexchange.com/questions/28826/magento-website-hacked-encryption-code-in-all-php-files

Generally they can do anything with this webshell and inject contents from the remote servers into your website.

This webshell code does not help much. Your website is compromised. I highly recommend to delete the website (files + database) and install a clean backup, check accesslogs how they came in and fix the security hole.

After they got in, they could have done much more, also deleting payloads and webshells after executing code.

Often the problem are insecure plugins and themes. There are many vulnerabilities.
https://wpvulndb.com/

It is highly advised to install all updates (even for paid themes) and install some solution like NinjaFirewall http://nintechnet.com/ninjafirewall/wp-edition/


Does NTLM authentication via HTTP not need a user name? Because of a vulnerability that has been found in Exchange Server I was trying to run that attack on our local system to see if the workaround can successfully prevent it.

I found a description of NTLM Authentication for HTTP which describes three messages in an NTLM handshake, namely Type 1, 2 and 3. The first one uses only the host name of the client machine and the domain name for generating the hash value. The second one is the server's challenge and the final one that ultimately authenticates the user to the server is created by the client using the nonce from the challenge and also user name and password.

When connecting to the Exchange Web Service using my credentials I was able to extract the correct user name from the Type-3 (AUTHENTICATION) message. But when I looked at the AUTHENTICATION message that the server sent when sending a push message there was neither a user name nor a domain or host name in it.

Also in another question it has been pointed out that in the first step of an NTLM authentication the client sends the user name to the server which seems not to have been the case here. What am I missing? Are there different variations of messages and flows for NTLM authentication via HTTP and other protocols?

There are two versions of NTLM, there are signing and sealing options, and other variations.  the best resource is this.  http://davenport.sourceforge.net/ntlm.html NTLM Auth always needs a username, or the DC can't lookup the users NT Hash and validate the math.


Can I get rid of storing user secrets by using OpenID, and what do I need to store? What information do you have to keep about a user to be an OpenID consumer?

I want to use OpenID to let users register and authenticate on my system.  So while I'm at it I want to not duplicate effort, and eliminate unnecessary passwords, etc from being stored.

I assume that besides the user's Profile details, you would need to store a copy of the user's Authentication/ID token from the ID provider as well as the user's ID URI, and a recovery email address in case the ID provider becomes inaccessible or the user wants to link a new ID provider to their account on your system.  It also appears that there is a temporary "request" Token used during sign-up and/or during re-authentication, but this is short lived and used once only, so may not need to be stored in the database ever.

Does different ID providers, eg Facebook, Twitter, LinkedIn, Google Connect all provide similar enough authentication tokens that I can simply call the database columns something like "IDProviderToken" and "IDProviderURI", or do I need data specific to Facebook/Google/etc ?

What you keep about the user is your own decision. The most basic implementation is keeping a user ID (the one received from the open ID provider) and the token you receive from the open ID provider (which includes access token, expiration and refresh token).
whatever you wish to keep beyond that is up to you.

As much as I know every openid connect provider must respond with the same data structure... that is part of the protocol, but openid has three versions: 1.0, 2.0 and connect

Some examples of providers:
Google and Microsoft Azure now use openid connect for their openid services.
Yahoo uses openid 2.0
You mentioned Facebook - they are not an openid provider, they have their own unique protocol


How do I know if my computer is being used for a botnet-based DDoS attack? A botnet is a collection of compromised computers, each of which is
  known as a 'bot', connected to the Internet. When a computer is
  compromised by an attacker, there is often code within the malware
  that commands it to become part of a botnet. The "botmaster" or "bot
  herder" controls these compromised computers via standards-based
  network protocols such as IRC and http.

Is there a way to detect that your computer is being used in a botnet-based DDoS attack?

There is some tool such as a software that could detect strange traffic and exploit activity from my computer?

There's no easy way to detect whether your machine is part of a botnet.  Instead, the best defense is prevention: avoid getting infected in the first place.

There is lots and lots written on how to avoid security breaches, too much to repeat here.  For a starter, you could read, e.g., a security guide for non-technical users, Windows hardening, Hardening Linux Server, or Secure Linux Desktop.  Happy reading!


How does gpg know that a passphrase is bad in symmetric encryption? Following from, What information is leaked from an OpenPGP encrypted file?, which was very helpful, I'd like to ask a similar question regarding symmetric encryption.
For example, in a file encrypted with

gpg -c --cipher-algo AES256 --armor -o file.asc file.txt

Is the passphrase hash (with salt and iterations as specified by --s2k-count) stored in the file.asc? How does gpg know a passphrase is correct?

The answer is given in RFC4880, http://www.ietf.org/rfc/rfc4880.txt in section "5.7.  Symmetrically Encrypted Data Packet (Tag 9)"
In short, the key generated from the passphrase is used to encrypt a block of random data, and two last octets of the data are repeated. This encrypted data is included in every symmetrically encrypted message, in the packet. GPG first decrypts this block with a given key derived from the passphrase (see string-to-key in the RFC), and checks that the last two octets are repeats of the previous two octets. If not, the passphrase is definitely not correct. If yes, the passphrase MAY be correct. Then the decryption of data occurs.

Hence, no hash is stored in the data packet.


What are the security risks in leaving 'sudo' inside my production code? I have a script that can only run successfully with root permissions

But in development it's really hard to run with root permissions (in my development environment) so I add 'sudo' when ever it's required inside the code and remove it before I push changes to production.

Obviously this is not a good practice since eventually a 'sudo' would slip in.

So I wonder what are the security risks of leaving it right there?

The security risks are in the sudoers file.

if the sudoers file restricts the users to only safe operations  and is either passwordless or requires a password every time. there is no danger.

This means that the actions performed under sudo must be safe and free from exploits like shell injection, alias or path attacks, and buffer-overun.

Where practical instead grant group permissions to the users. Eg. group "dialout" for serial ports. group "lp" for parallel ports, "audio" for sound devices, "adm" if you need to read the logs, etc.


What is the ultimate goal of hacking a webserver? Recently I noticed a lot of traffic generated by automated bots that were checking for vulnerabilities in my web server. They were mainly looking for ways to hack into plesk/wordpress which I don't even have running on the server.

Now my question is, what are hackers trying to accomplish by hacking the server. I mean, even IF they manage to hack into plesk and take over some sites for a day or two, I would still be able to hard-reset the whole server thus rendering their efforts useless again?

Why are they doing it? What's the catch?

The ultimate goal? It heavily depends on the initiator of the attack, but here are some ideas:

Attacker interested in financial gains:

It may be worth huge amounts of effort to target high traffic webservers/domains that enjoy a good reputation (The domain name is associated with a trustful service) and then apply phishing techniques (Credit cards, paypal, bitcoin credentials, ...) on the many visiting users. The users are very likely to submit such personal information, because the user feels safe.
Integrate the server in a botnet: Servers have usually much more networking power then personal computers and can leverage a DDOS attack.
Often financial information as credit cards or paypal billing addresses are stored on the webserver (or the database, that is also compromised by taking over a webserver)
Interest in other valuable information such as user credentials or closed source applications that are valuable.
Using the captured server as a means to hide traffic. Back in the day I used to install socks5 servers (Can also be implemented in PHP if no compiler is available) to proxify traffic.
Using the compromised server to redirect traffic in order to exploit user agents. Javascript redirection to a attacking server with a exploit kit istalled like blackhole. This step might me as sophisticated as you wish: Only redirect clients that have specific plugins installed (Java, flash, silverlight), are a concrete User Agent (old, exploitable IE browser versions...)

Otherwise:

Pure curiosity
Just testing if you can take it over due to a self set intellectual challenge
Defacing for political purposes (anonymous?)
Vandalism (lulzsec)
Use the web server as starting point for further attacks like:
Privilege escalation (Can we gain root privs?)
Are internal hosts/networks available from the server (Might be the case when the webserver also works as a reverse proxy)

There are many reasons. Hope you get the point.


How secure is BLE for a door lock I am interested in setting up a trigger that can unlock door locks using an iPhone. The lock and unlock mechanism is not an issue as I have an API end point for this once authorized it is more an issue around the trigger.

I have seen that in the wikipedia artical for iBeacons it says that these are not secure although some companies offer versions that change the UUID to prevent cloning. For this reason companies like paypal just use them as initial triggers.

Is it correct to say then locks such as this (https://9to5mac.com/2015/04/24/apple-watch-hotel-room-key/) are using a priority security mechanism and custom BLE rather than iBecons?

The security is not in the BLE technology, but in the way the company implements the solution.  Your best bet is to go with a door lock manufactured by a reputable security company that boasts a 3rd party vet the security of the device.


A New Blog Post is showing on top of my home page from Unknown user cyberanon - How to Remove the post? I have just launched our brand new blog website (php/mysql). I don't have any idea about cyber security. Yesterday we published a topic on coronavirus vaccine. I just noticed a new post is sitting on the home page Title: "Mr.Krungzx" and user "cyberanon". I tried to search in the admin panel, but didn't find anything related to this unknown post. We are using SSL to make our website secure. But seems like nothing worked, and I am clueless what to do next or what are the possible resolution and how to clean up this post from our web page also make sure this don't happen again. Appreciate your help.

This can be all sorts of things.
As your blog uses a MySQL database, check if the unwanted post is in there. If it is, and no-one authorized placed it there, you might have a breach somewhere.

Make sure that the database (phpMyAdmin?) and controlpanel of the blog are not using default or easy login credentials (e.g 'root' without password). Also check that visitors can not create new blog posts.

If the post is on the homepage but not in the database, try checking the source files which generate this page. There might be something in there.

Furthermore, using SSL is not making a website secure. It secures (encrypts) the connection between a visitor (client) and the webserver. It does not secure the application itself against malicious actors.

For more help please give us some more information, is the blog running on a known platform (e.g WordPress) or custom build? Can guests place new content or comments?


ssl handshake failure unable to get local issuer certificate I have an issue with new integration that I am working on it.
I should consume a web service provided by external company and this service is over https, so in order to integrate with them, they have shared Three certificates:

Root.cer
Sahred.cer and the issuer is Root.cer
user.cer and the issuer is Shared.cer

I have installed all of them and I run below commands with no lock.

openssl connect command to the web service with showcerts option

openssl s_client -showcerts -connect https://example.com:8443

output:

CONNECTED(00000003)
depth=1 C = UK, O = EXA, OU = EXA eTrust Center, CN = EXA Shared CA
verify error:num=20:unable to get local issuer certificate
140539532310416:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1493:SSL alert number 40
140539532310416:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
---
Certificate chain
 0 s:/C=SA/O=EXA/OU=EXA eTrust Center/CN=example.com
   i:/C=SA/O=EXA/OU=EXA eTrust Center/CN=EXA Shared CA
-----BEGIN CERTIFICATE-----
-----------
-----END CERTIFICATE-----
 1 s:/C=SA/O=EXA/OU=EXA eTrust Center/CN=EXA Shared CA
   i:/C=SA/O=EXA/OU=EXA eTrust Center/CN=EXA Root CA
-----BEGIN CERTIFICATE-----
------
-----END CERTIFICATE-----
---
Server certificate
subject=/C=SA/O=EXA/OU=EXA eTrust Center/CN=example.com
issuer=/C=SA/O=EXA/OU=EXA eTrust Center/CN=EXA Shared CA
---
No client certificate CA names sent

curl command with handshake debugging:

curl -X POST https://example.com:8443 -iv

output:

 * TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
 * TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
 * TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [87 bytes data]
 * TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [3593 bytes data]
 * TLSv1.2 (OUT), TLS alert, Server hello (2):
} [2 bytes data]
 * SSL certificate problem: unable to get local issuer certificate
 * stopped the pause stream!

curl command with handshake debugging and skip verification:

curl -X POST https://example.com:8443 -iv -k

output:

 * TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
 * TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
 * TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [87 bytes data]
 * TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [3593 bytes data]
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
 * TLSv1.2 (IN), TLS handshake, Request CERT (13):
{ [36 bytes data]
 * TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
 * TLSv1.2 (OUT), TLS handshake, Certificate (11):
} [7 bytes data]
 * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
 * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
 * TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
 * TLSv1.2 (IN), TLS alert, Server hello (2):
{ [2 bytes data]
 * error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

My Questions:

What are the benefits from creating three certificates with issuer
like that ?
why the ssl handshake has failed ? Did I miss any thing in my commands ?
Do you any idea how can I deal with these certificates or at lease how this communication works ?
I really don't get it how this communication works. How can I submit these certificates without any private key. Based on my
understanding when we want to create ssl based authentication I
should create a public key and private key and I should share this
public key with the external company, so they can decrypt the message
when I encrypted by my private key. is this right ?

also I have posted a question with java in stackoverflow with no lock, you can take a look for more info
https://stackoverflow.com/questions/53420158/ssl-handshake-failure-client-certifcate-not-being-sent

Some basic reading on TLS / SSL
"SSL" is the old name, I'll call it "TLS" in this post.
You should do some reading to get a basic understanding of how TLS works. Googling "How does the TLS handshake work?" should get you some good articles. We also have an overall primer post (thought it may be longer and more detailed than you want): How does SSL/TLS work?
Here is a curl-specific article about how TLS works: https://curl.haxx.se/docs/sslcerts.html

Why a CA chain?
It's normal for HTTPS certificates to have that structure with a root CA, and issuing CA, and the website cert, for example take a look at the cert for this page:

To answer your 4th question: The point of these certs is so that the server can prove to you that it is who it says it is, therefore the website keeps the private key, and you (the client) can use its public key (aka "certificate") to verify that is the authentic server. Nowhere in there is the client proving its identity to the server (that's usually accomplished by including an API key in the request).

Fixing your error
Remember that TLS is about establishing trust; validation of a server's certificate involves these steps:

Is the End-User cert valid? Who issued it and do I trust them?
Is the Intermediate CA cert valid? Who issued it and do I trust them?
Is the Root CA cert valid? Do I trust it?

So when validating, you "chain" up to the root, and then check your "trust store" (a file on your computer of root CA certs that are "trusted") to see if that root cert is in there. OSes, browsers, etc will all ship with a list of root CA certs that it trusts. in the case of curl, that's a file on disk called curl-ca-bundle.crt.
My guess is that the root CA you're dealing with is not in curl's default list, so you need to add it manually. In the curl article I linked to above, they explain how to do this in Step 4.
Good luck, and welcome to the world of TLS and certificates!


Can a DNS provider take action if a phishing attempt comes from one of their domains? I received a delightful phishing attempt:

  Please keep this email for your crypto-currency records.    Someone recently used your
  password to try to sign into your Wallet Accoun   (CASE ID:9098853964)    We
  prevented this sign-in attempt, because this might be a criminal hacker that  was trying
  to access your Bitcoin Account. Here are some details of the event:  - Tuesday 17:45:29 AM
  UTC  - IP Address:  107.145.285.2  (Moscow, Russia)    If you did not try to
  access your Bitcoin wallet at that time, this was an  unauthorized attempt and you should
  change your Wallet password immediately.    Reset your password by CLICKING HERE    Best
  Regards,  BlockChain Team    NOTE: If you do not want these warnings you can unsubscribe
  here    (copyright BlockTeam 2016)

(note the extremely interesting IP address: 107.145.285.2 - I guess in Soviet Russia IP address specifies specification)

The URLs specified in the email are registered through GoDaddy (I can add the domains here if that's appropriate), so I was wondering if GoDaddy has any responsibility or cares. Can DNS providers take action if they have phishing sites hosted on domains registered through them?

Update: As I looked through the email headers I just noticed this little guy:

  X-PHISHTEST: This is a phishing security test from KnowBe4 that has been
   authorized by the recipient organization

A quick search for KnowBe4 reveals that they're a security testing organization (or at least someone is making it look like them). So it looks like it was a phishing attempt but only by an organization that's hired to be nefarious.

I will reluctantly reserve comment on the trustworthiness of GoDaddy since you can look that up yourself.

But the DNS service has little responsibility. However, the hosting provider is a different matter - in some countries at least.

There is nothing stopping you reporting it, though, to the abuse mailbox for the GoDaddy registrar, it is possible they will take action, especially if lots of people do the same. If they have their act together, they might also pass on the information to other authorities that could aggregate such intelligence and the address may end up in a blocklist.

Howeverx2, you'd need to ask yourself whether you have the time to do this for each piece of spam you get through.


Protecting an external authentication server against CSRF I have a web application which uses an external authentication server for obtaining a session. When a client tries to login, the browser is making requests towards the external authentication server until a cookie is obtained. Note that the client has all the API calls towards the external authentication server.
My concern is that an attacker can clone my web application and trick the user into going to his web application, for example with typosquatting. The malicious web application can then interact with the legitimate external authentication server. Doing this will give the malicious web application a legitimate cookie, which the attacker can use on the legitimate web application. I consider this to be a form of CSRF.
There are two approaches I can think of to tackle this:

Have CORS enabled on the external authentication server. Allow the Origin to be equal to only one value, i.e. the web application URL. Now, when the malicious web application tries to interact with the legitimate external authentication server, the client's browser will include a Origin header which the external authentication server will reject (due to CORS).
Use tokens as a classic CSRF protection. Essentially, connect the legitimate web application server talk to external authentication server, and have them establish a transient token for each client (e.g. based on the IP). The client would get this token as part of the login form and send it to the external authentication server with the requests. The external server can then decide if the token is valid for that specific client.

Client makes a request to web application -> Web application establishes a token with the external authentication server -> Web application gives the client the token -> The client sends the token to the external authentication server with the requests.

I would like to evade the second option if possible, taking into account that I have some additional risk of assuming that the clients always use a CORS compatible browser. Do you think the first option is enough? If not, are your concerns solved by the second option? Is there another option that I am overlooking?
Thank you!

After some time I realised how this can be prevented without any of the complications I listed above.
Essentially, the external authentication provider needs to explicitly trust the web server. This trust can be established by authentication, e.g. a shared secret.
Therefore, an attacker cannot clone the server as the clone will not be trusted by the external authentication provider.


Why should I restrict the content type of files be uploaded to my site? We are building an application where users can upload resumes in our system for our administrators to download.  We are having a debate about restricting the content type of the files that can be uploaded.

I'm having a hard time piecing together exactly the security concerns I have with allowing any content type to be uploaded.

Is there a security risk of allowing any content type to be uploaded?

It must be noted that a file does not have an inherent "content-type" per se. A file is a bunch of bytes, and has a name. When you download a file from a Web server, the server infers a content-type (such as "application/pdf") from whatever clues it can find, mostly the so-called "extension" (the few letters at the end of the file name; e.g. ".pdf" is assumed to indicate a PDF file), and sometimes the file contents themselves: for instance, when a Web server distributes an HTML file, it also looks within the file header for a "meta" tag which would override the default choice for Content-type, like this:

<head>
<meta http-equiv="content-type" content="text/html;charset=UTF-8" />
</head>

So you have two operations on your server: upload, and download. Upload is mostly safe: the file comes, and is stored. Download can be a worry: when an administrator will download a file, he will do so by clicking on some link within a Web browser, and the Web server will infer a content-type, as described above. The Web browser will then use the content-type to decide what to do with the downloaded file, and this might not necessarily be "suggest to the user to save it somewhere". For instance, if someone uploads a .html file, the Web browser will interpret it as HTML, displaying it and possibly executing whatever Javascript is in it. Furthermore, the file will come from your own server, so chances are that the administrator Web browser will trust that file by default. Various nasty things may happen at that point.

So you should filter the content-types under which you will serve the files when downloaded; and mind the file name, too, because even if the file is just saved on the administrator system, it may still be a .exe file which the administrator will execute when clicking on it.

Moreover, allowing any kind of file to appear on your server may be an indirect tool to leverage an attack. There are some security holes in which the attacker can somehow force the execution of an arbitrary file on the server; an unfiltered upload mechanism allows the attacker to first push exactly the kind of executable file he would like to see executed on the server.


How secure is automatic authentication in Skype? How secure is checking the automatic authentication option in Skype client? What if I sign in with Microsoft account instead of Skype id? What if both accounts are merged? Is there any documentation on how it works in recent versions? For example, whether it stores a plain text password, or how easily it can be retrieved. More likely unofficial information, from people interested in the subject (for example, you would get surprised how secure Windows Credential Manager actually is). But it would be good if Microsoft documented how it works somewhere, so we can feel confident that our main account is safe.

My concern is that the Microsoft password is just too important, giving access to all Microsoft services, while Skype account is more specific. I do not want my main password having any chance to get compromised just because I do not want to keep typing a password all the time in Skype. Unfortunately, Microsoft have not copied Google's application-specific passwords yet. That allows creating secondary passwords for Google account, protecting your main password from getting stored anywhere.

Not stored securely, but stored at all

Please note, I am not worried about whether the main password is stored insecurely, but stored at all. Whatever encryption is used, you can simply copy whole Skype profile without decrypting anything, and possibly with some additional hacking, you could at least impersonate the user on Skype (assuming that a compromised stored password will generally mean a compromised computer, at that point it should not be that hard).

Even so, it could be possible that some security flaw was explored by the attacker in order to elevate the privileges from the Skype account and get access to the main Microsoft account. I assume their security is good regarding this, but it becomes much more threatening if the main account password or some sort of authentication token is stored, in any form (again, you can simply reuse the encrypted data in another profile or in your desired hack).

It is really hard to judge its percentage of security with a couple of queries.

Obviously none of the users who gives "Remember password" option or automatic authentication wants their password to get compromised.

If you really do not want your Microsoft services to be accessed by any other application, then i suggest you consider not merging it with other applications.

And remember that just because of merging your Microsoft account with Skype doesn't mean that your Microsoft account is made less secure. It means that you can have a centralized place where you can manage and access both of your accounts.

Microsoft might not have implemented Google's application-specific passwords yet. But that doesn't make it vulnerable for your password since Microsoft has it's own encryption system which uses some of the top most security algorithms (I do not want to go deeper as it may be off topic).That proves that your password or any other sensitive information will be hashed using an advanced encryption system and secured.

And to answer you question, Yes it is secure (again, not in terms of percentage).