Is SQL Injection possible in String Concatenation When all Variables are created by the Program

Is it currently vulnerable? No.

Should you change it anyway? Probably

If you are putting variables in an SQL query then you should use prepared queries. They make almost no impact on your code base and usually have only a tiny impact on performance. As a result, the cost of using prepared queries is small. Obviously you would ask "But there is no vulnerability here so why should I take the time to change it?". The answer is simple: you never know how your code will change later

What if down the road management decides they want to let users select the date range themselves? A hurried programmer updates the getDates method to return the input from the user and performs no validation on it (the programmer is in a rush after all, and doesn't think to check everywhere and see how the return value is used).

Now you do have an SQL vulnerability. It may seem like a stretch, but many security weaknesses happen as a result of small incremental code changes where someone coming in later no longer remembers the full context of the code in question. As a result, my rule of thumb is that as long as the prepared query is easy to put in with minimal performance issues then use prepared queries for your variables  even if it (currently) seems unnecessary.

Also, I think it is better to be in the habit of using prepared queries and only skipping them after careful consideration, rather than being in the habit of skipping prepared queries and only using them after careful consideration. The later habit will generate many more security problems.


My guess is that you are behind some firewall which is blocking the connections. I have no problems in accessing these hosts.

  how can one send e-mails when it is closed?

If you are behind some company firewall you are probably supposed to use the companies internal mail server only which is usually not blocked.


Should I disable TLS 1.0 and TLS 1.1 support on my web servers

To answer your first question:  If you have clients that do not support TLS 1.2, and these clients connect to your server using TLS 1.0 or TLS 1.1, and you disable TLS 1.0 and TLS 1.1 on your server, then these clients will not be able to connect to your server.

With regard to the pro's and con's of continuing to support TLS 1.0 and TLS 1.1:  Many organizations have disabled (or will soon disable) TLS 1.0 and TLS 1.1, because of known vulnerabilities in these versions of TLS.  See this article for more information on these vulnerabilities.  Disabling TLS 1.0 and TLS 1.1 on your server will protect your server and your clients from these vulnerabilities.  However, if you have clients that support TLS 1.0 and/or TLS 1.1, but not TLS 1.2, then these clients will not be able to connect to your server if you disable TLS 1.0 and TLS 1.1.

Having said that, all mainstream web browsers have supported TLS 1.2 for quite some time now, so disabling TLS 1.0 and TLS 1.1 will probably affect very few of your users, if most of your users connect to your site with a recent version of a mainstream web browser.

For what it's worth, StackExchange recently disabled TLS 1.0 and TLS 1.1. for all of their sites, and posted a very informative write-up of the process here.  Interestingly, they found that less than 1% of the TLS connections to their servers used TLS 1.0 and TLS 1.1 (and they suspect that most of these connections were from bots).

With regard to your final question about determining how many of your clients are still connecting to your server using TLS 1.0 and TLS 1.1, most web servers have the ability to log the TLS version that was used for each request from a client.  Check the documentation for your web server to see how to enable this.

Related: What will happen to older browsers if I disable SSLv3 on my webserver?


How can a system verify an online password using a phone keypad?

One possibility is to store a second hashed password. Store the hashed real password, and at the same time map that plaintext password to the keypad equivalent, and store the keypad equivalent as a second hash (and second salt).


Continuous Integration for Exploit Development

For checking if a vulnerability has been patched or not, why not just have a fixed value for EIP, say like DEADDAED and make sure it matches by getting the output through some debugging module. If it matches the vulnerability is still there.
If it doesn't match but the application crashes, you most likely have the vulnerability there but need to modify the exploit code for it to work properly.

For testing it on new versions, the exploit shouldn't work. For example, I have an IE exploit and the ASLR is bypassed using mshtml. If mshtml is updated in the next IE update, my exploit will not work because of the offset changes that have occurred in the patched mshtml. Unless maybe, you are using some other dll in which no changes have occurred.

As far as I can see it, you need to test it on one version of the software in concern to determine if it is patched or not.

The other parts of cloning a VM, updating the software etc. should be as you stated. The only thing with a MSI installer is you could try doing a silent install, so you avoid the dialog boxes.


You need a couple of pieces of information in addition to the card number and the PIN, but this is pretty close to accurate.  Card cloning is a common crime and there are criminals who even do it right on the machine itself.  By copying the ATM card and recording the PIN, it is possible to access the account and withdraw money from it.  Fake faceplates can be installed on most ATMs to read the magnetic strip on the card and record the PIN number entered.  This is why it is always important to examine an ATM before you use it to ensure that it has not been tampered with.


What are the best security practices to install a C# Web App on client servers?

This sounds you are just asking for problems.

1) Authority stealing - What exactly do you mean by this?  If you write your Web Application the correct way, then it will only be able to do things your client allows, find out what sort of configuration they are using.

2) Read files with sensitive data - I suggest you don't attempt to do this.  Your web application should not be on a computer with sensitive data if its accesible to the internet.

3) Software tweaking - Say What?

4) Any security issues - This is not possible.  Considering you are even asking how to prevent this, means you will have security issues, even Microsoft has security issues.

Encrypting the Web.Config only protects the contents within it, if there is nothing senistive within it, it really serves no purpose to encrypt it.

It sounds you are way over your head.


CVV is calculated:

  [CVV Generate] verb generates a CVV that is based on the information that the PAN_data, the expiration_date, and the service_code parameters provide. This verb uses the Key-A and the Key-B keys to cryptographically process this information.

Source: https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.wskc.doc/wskc_r_csg.html

This calculation can only be done by the card issuer due to the use of a pair of Cryptographic keys which is known only to the card issuer.


Web browser initiating connection on non-standard ports. Should it be blocked?

What you should do is resolve the IP addresses to see who uses them and check (IANA) port designations. Then adding audit rules (only for local clients though) gives you at least a time stamp, process and user Id, forcing clients through a proxy gets you at least a time stamp and host name and capturing packets (ulogd, tcpdump, Snort rule) may provide session details. Combined that should provide a better basis for analysis as an IP address and port combo alone doesn't necessarily prove much these days.


Are Citrix Netscalers vulnerable to shellshock bash command?

Netscalers appear to be vulnerable!

Netscaler is running GNU bash, version 2.05b.0(1) , which is stated as vulnerable in http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271

Here is what I get:

root@ns# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
root@ns#

Response from Citrix on the ticket I raised:

" I would like to inform you that our security team is looking into this issue and this is under investigation, we are expecting an Update soon on this. "

while we wait for official fix release from Citrix you might have to use your IPS (in my case palo alto) signatures to deny such attacks for remote websites and keep watch/restrict management access on Netscaler .


A short and obvious answer to your question's header "Can a simple webpage link contain any virus or do harm to my system?" is YES!
Yes, your system can be easily compromised by exploiting lots of vulnerabilities in various components of the web browser, e.g. plugins.

In addition to this - your details can be collected by the attacker to conduct a recon/scan on the collected IP.


Token contains a reflected XSS vector in the  tag error in Chrome

You should use URL encoding not HTML encoding. If you URL encode the back_url parameter the quotes shouldn't trigger any XSS warnings and you won't need to deal with converting them back and forth to make the redirect work correctly.

Also be wary that this design introduces an open redirect vulnerability into your application. An attacker can craft a URL for your website that redirects to an attacker controlled site when they use the back button if you're not properly sanitizing the back_url parameter.


How to prevent pay per show/click abuse?

As with all fraud-detection mechanisms, this problem is inherently unsolvable in the absolute sense, as whenever you come up with a solution, the attackers will simply modify their attack to account for it. This is also why you simply cannot find a "ready-made" solution for this type of problem on a site like this. Once a solution is posted, it becomes the template for the fraudsters in determining how to avoid detection.

But that doesn't mean there's nothing you can do.

This is a classic data-mining problem. With a large enough sample set, you watch for patterns and statistical anomalies the attributes associated with the data. It could be the user agent, netblock, referrer, timing attributes, or just about anything that the attacker didn't think to compensate for. When you see an increase in traffic that all share some unusual attribute, there's a higher statistical likelihood that you're seeing non-normal (potentially fraudulent) traffic. The math behind what you'll need to implement will almost certainly be based on Bayesian analysis which will help you flag the outliers.

The larger your dataset the better you can eliminate errors, and therefore the more accurate your model will become. This is one of the primary reasons why very large ad networks can do a much better job at this than smaller ones; the sheer data volume can be a huge advantage in itself.


The answer completely depends on the encryption used, which you said you don't know.  Odds are, if it is anything modern, the answer is "no" as one of the comments says.  Modern encryption systems are highly resistant to known plain text cryptanlysis.

However, if this were a simple substitution cipher, or even a poly-alphabetic substitution cipher, then "yes," it's likely crack-able.

If the plain text was XOR'ed with a relatively short, repeating key, that too would be possible to crack.

But ultimately, it depends on which crypto was used, and if it is anything reasonably modern and standard, the answer is no.


Any way to obfuscate *when* two end hosts are communicating?

So, you're looking at how to handle basic Traffic Analysis?

The basic countermeasures from Wikipedia (the above link) are exactly what I expected:

"It is difficult to defeat traffic analysis without both encrypting messages and masking the channel. When no actual messages are being sent, the channel can be masked by sending dummy traffic, similar to the encrypted traffic, thereby keeping bandwidth usage constant."

The real answer is to set up constant bidirectional traffic, at a fixed bit rate, all going through your current encryption.

Alternately, if you can handle non-realtime data, then simply set up a schedule.  Transmit exactly N bytes every M time units in each direction, on slightly different schedules.  For instance, machine 1 transmits exactly 8MB at 15 minutes after every hour, and machine 2 transmits exactly 8MB at 45 minutes after every hour, no matter what.

One primitive but easy way to generate the fixed data size is to create a fresh Truecrypt container for every transfer of that size, then dump it over the encrypted link; better ways are no doubt available.

Alternately, change from MB to KB, and from minutes after every hour to seconds after every minute.

You definitely want NTP running properly and reliable on these machines - synchronized clocks are required.


it is possible to make a copy of an iPhone?

a simple itunes backup actually backs everything up, down to the arrangement of apps on the home screens. to use the backup, you'd need another iphone to restore the backup to, that is capable of running the same version of iOS.
i would expect you'd need to know the passcode of the phone, to do the backup in the first place. it might also ask for the icloud password, on the cloned iphone. i can't remember.


Is there any bias in this random selection from a dictionary?

You are right to use /dev/urandom. Don't use /dev/random: it is not better than /dev/urandom, and in some ways it is worse. This page is a nice summary on that subject.

Your entropy calculation is correct. Entropy is a measure of what the password generation process could produce, not of what it has produced; hence, if you have n words in your list and pick each word randomly and uniformly, then you get exactly log n bits of entropy per word (base-2 logarithm here). The entropy is not reduced if you happen to pick several times the same word. More detailed explanations are available in this answer.

Your looping test:

next if ($n >= @words); # don't use %, it will bias the randomness

is correct. You avoided the bias induced by the modulo operation. However, there is a slight inefficiency here, in that you generate and integral number of bytes. For instance, if your list contains, say, 1000 words, then you will produce sequences of two bytes, hence a number in the 0..65535 range. You will have to loop on average 65.536 times before hitting a number in the 0..999 range. Depending on your context, this may or may not matter; modern computers are very fast, and if the password generation is human driven (you produce a single password for a human user who is waiting for it) then the computer has a lot of computing power to spare, and the dozens/hundreds of loops won't even be noticeable.

If you want to be more efficient, there are mainly two improvements that can be made:

Truncate the byte sequence to the minimal length in bits. For instance, if you have a 1000-word list, the minimal bit length is 10 (because 210 = 1024). This would entail masking out (i.e. clearing) the top 6 bits of the 16-bit random integer. In that specific case, this would mean that looping would happen only in 2.4% of cases, i.e. quite rarely. On a more general basis, truncation to the correct bit length ensures that the average number of loop instances will be no more than 2.
Use a combination of exclusion (when the number is too high) and modulo reduction. With a 1000-word list, this would mean generating a number in the 0..64999 range, and then reducing modulo 1000: the next clause would be triggered only when the 16-bit integer falls in the 65000..65535 range (i.e. not often at all), and the modulo would not induce a bias because 65000 is a multiple of 1000. You might want to take inspiration from the documentation for Java's java.util.Random.nextInt(int bound) method (the documentation includes a code excerpt which is enlightening; this is Java, but the concept applies to other languages as well).

I would advise against the random capitalisations: they don't directly hurt security, but they consume human memory resources for a comparatively mediocre entropy gain. That is, if by not using that capitalisation, you make enough room in your brain to remember a couple of extra words, then that's probably a better bargain. Furthermore, having an all-lowercase password makes for smoother password entry, especially on smartphones.


how to test for csrf if the web application is not using tokens and there are no users defined for that application?

Related: CSRF protection for unauthenticated requests, actions, searches or comments?.

This question is not a duplicate as you are asking how to test for it.

In just the same way you would test for normal CSRF. Instigate a request to the server that would simulate the request arriving cross-domain. That is:

Origin and referer headers appropriately set.
No headers present that cannot be set cross-domain (e.g. X-Requested-With).
No tokens present that an attacker cannot determine without crossing origins in the browser session.

Of course you can always test for it by actually hosting your own page to make a cross-domain request to the site you are testing (being careful to strip any additional tokens that wouldn't be known of course).


Why do law-abiding citizens need strong security?

You don't need to lock your front door unless you're a thief.

It's the same idea in all relevant respects.

Each person needs to take reasonable measures to protect himself and his property from those who would harm him or his property, in accordance with his best judgment of the risks.

You buy a lock and lock your front door if you live in a city, in close proximity to hundreds of thousands of others. There is a reason for that. And it's the same reason why you lock your Internet front door.


Is it possible to defend against a backscatter attack?

The problem is that autoresponders exist, and that they reply to the senders email address, which is easy to spoof.

There is nothing you can do to prevent this. Filtering is ineffective since they are (from the computer's perspective) legitimate messages. Banning the IP is also ineffective since any particular IP is unlikely to send more than a few messages.


Why does "" in a JS string cause a broken page/denial of service for that page?

The correct answer to this is "because the HTML parser in the spec says so".

From the normal "inside a script tag" state, An HTML comment start (<!--) puts the parser into an escaped state, and from that mode a script start tag (<script>) puts into into a double escaped state in which script closing tags (</script>) are ignored.

Why on Earth does it do this? Backwards compatibility for inserting code into browsers that didn't support JS. Chaals gives a great answer on https://github.com/w3c/html/issues/1617, and I'll show his example of what was once normal code here:

<script>
  <!--    //hide from non-JS browsers
  function doSomething() {
    var coolScript = "<script>" + theCodeICopied + "</script>";
    document.write(coolScript);
  }
  // And if you forget to close your comment here, things go funnny
  -->
</script>

So now we're stuck with this page-breaking vulnerability unless you escape both start AND end script tags.


PSD2 compliant two factor authentication

tl;dr; Nobody can say for sure and this is highly debatable

Little history: there was a change from "trusted execution environment" to "secure execution environment". It is documented here: https://www.eba.europa.eu/documents/10180/1761863/Final+draft+RTS+on+SCA+and+CSC+under+PSD2+(EBA-RTS-2017-02).pdf

Most of the industry (that I know of) agrees that this implies hardware based TEE is not a requirement.
There are some reasons provided in that document:

  Article 6(2) (now Article 9(2)) does not refer to segregation, only
  Article 2.2.b does. See comments [10] and [11] on that. The EBA has
  therefore not made any changes to the Article. However, in relation to
  comment i), the EBA agrees that PSPs can mitigate only the risks
  within their realm of competence. The EBA has made changes to Article
  6(3) (now Article 9(3)) to specify that the focus is on the software
  used by the PSP rather than the hardware itself.

EBA refused multiple requests to be more specific on how to achieve execution environments separation. From this we can understand that you should care only about proper software implementation, but what does that mean? Lets dig deeper.

There is this older document with some less vague language:
https://www.eba.europa.eu/documents/10180/1548183/Consultation+Paper+on+draft+RTS+on+SCA+and+CSC+%28EBA-CP-2016-11%29.pdf

  Furthermore, the authentication procedure should ensure the confidentiality, authenticity and integrity of the information
  displayed to the payer through all phases of the authentication
  procedure including generation, transmission and use of the
  authentication code. To that end, the channel, device or mobile
  application where the information about the amount and the payee of
  the transaction is displayed should be independent or segregated from
  the channel, device or mobile application used for initiating the
  payment. This can be done, for example, via an independent channel to
  prevent any manipulation of the transaction details through the
  initiation process of the payment transaction.

Considering all this, I'm of the opinion, that using platform sandbox is a completely compliant solution. It might be not safest one though.
It's all makes sense when talking about mobile platforms, web environment is even more confusing, because it doesn't have any sandbox.


(This is a really high-level answer. Happy to receive clarification if you require it to be more specific.)

A privacy policy is defined by 2 pieces of information:

What the author considers to be private. This could be defined by legal or regulatory guidance in your state/country.
How private information is to be managed. This may include mandatory or optional controls. The necessity of these controls is usually graded by words such as must, required, shall, should, may, and optional.

For example, this is a high-level policy statement:

Personally identifiable information (e.g., name, date of birth, address) must be kept secure.

Now, secure is a vague word, but remember that this is a high-level policy statement. One would generally delve into the policy description or set of standards that define what secure means based on whether the information is in digital storage or on a physical medium such as paper.

Even then, security control for data stored in digital storage would be different for, say, a hard within a system in a datacenter versus tape backup on an off-site location managed by a third party.

Security controls managed by your organisation would generally have technical controls, whereas enforcing security controls operated by a third party would generally be managed using contractual controls.


What are the security threats when Googling and surfing when my Gmail account is open?

Your gmail account will be safe unless someone finds a Cross-Site Request Forgery (CSRF) vuln in gmail.

While nothing is 100% secure in the world, Google has proved to be very good at defending against security vulnerabilities. Even if a vulnerability is discovered, there is a good chance that it will be patched quickly. I rate it as highly unlikely that your account will be compromised in this manner.


Intercepting HTTP requests from a Java Application

You could do that with a Http Proxy.

In this related question you will find a list of proposed http proxies How can I intercept and modify HTTP requests?


A workplace installs custom certificates on personal devices, can this be used to decrypt HTTPS traffic?

Yes, they can MitM the traffic this way, using an internal certificate authority. There are two primary ways in which the MitM can work.

The first is to simply turn the edge gateway into a proxy, whereby TLS connections are made from the gateway to the server, and the gateway then generates server certificates on the fly from an internal CA in order to impersonate the remote server. Your system trusts the CA, so it trusts the server certificate.

The second is a slightly different take on the first. The gateway proxies the traffic similarly to the first method, except it only advertises static RSA cipher suites to the remote server. The reason for doing this is performance. With a static RSA key exchange (i.e. not Diffie-Hellman) the gateway can split the handshake as before in order to provide the client with a certificate generated via the internal CA, but instead of decrypting the content on the gateway and then re-encrypting it before proxying, it simply passes the same session key between the client and server. This way the gateway only has to decrypt the traffic once, using the captured session key, and never needs to re-encrypt it in order to proxy the traffic between client and server. This trick no longer works in TLS 1.3 as static RSA key exchange was removed.

Generally speaking this kind of TLS inspection is fairly commonplace in large organisations, particularly financials. Deploying it on BYOD devices is somewhat common, although you should consider the privacy and security implications that might arise from installing your company's internal CA certificate on your device. You need to ask yourself whether you trust that your IT security team is likely to be able to protect the signing keys, because if not then your device is liable to be MitM'ed by an attacker.


How to widely advertise a fixed important threat in widely used open source software?

Unfortunately there are no hard and fast rules about this kind of issue and with the very wide use of open source components and libraries it's inevitable that some companies won't update even after a long time (for example 200k servers still vulnerable to Heartbleed a year after release)

In terms of getting people to pay attention and patch, unfortunately it still seems like the only way is to publish vulnerability information widely and publicly, after an appropriate private notification period.

Exactly how long you want to have for that period is a matter of debate, with people going from 0-days all the way up to many months.

Perhaps a decent guideline would be to follow Cert's Responsible Disclosure Policy which releases after 45 days.

From the timeline you describe it sounds like you're well past that point already, so really if you want to see more people pay attention the best way may be to write up a blog post describing the issue and potential impact and circulate it widely.

Whilst it may seem cynical to suggest this, in terms of getting people to pay attention, marketing the vulnerability may be the best way to go.  If you look at recent vuln's that get publicity most have a catchy name ("Drown", "Heartbleed" etc) and the write-ups explain in quite clear terms the likely impact.  Then it's a case of it getting picked up in social media (twitter, reddit etc) and starting circulation amongst the InfoSec community.


Legality of cookie(set by other sites) tracking

Unless "website A" and "website B" are both subdomains of the same domain, what you want to do is impossible; if they are subdomains of the same domain, the same person or organization presumably controls both.  Consequently, legality is irrelevant.


Risks with OpenSSL verifying a signature with un-trusted PEM encoded public key

It seems like you're question boils down to two concerns: Can a logic flaw in your code be exploited? And Is the process efficient enough to not fall over under mild load? The concept itself doesn't seem unreasonable for a web server to accomplish, but if you're worried about the processing load, you can have the web server and php processor reside on different servers (or even put them on clusters of servers, with load balancers, queues, and caching layers, there's a real bottomless pit in the pursuit of high availability). But bear in mind that avoiding DoSs and app server crashes is a hard problem. The best we can do is make it hard/expensive for attackers to knock your server(s) over.

Limit the size of POST requests

Have the web server limit the size of post requests to limit the impact a single request can make. Here's an example using httpd .htaccess file

Check return codes

I see you're checking openssl for errors, you should also check the return code for base64 decode and make sure that operation succeeds, before passing garbage further on in the pipeline.

String size

I'm less familiar with how to do this in php, but setting an explicit max size and throwing errors if the input is larger or only handling a truncated version of long inputs.  But if a malicious user sends a 1GB block of text, at a high rate, and you are running expensive hashing operations, your server might get knocked over. But if you curtail it to a max size of 100kb before sending it to be hashed, you'll be doing better.

Regular Expressions

I'm a proponent of running user input against a regular expression before processing it (i.e. making sure the supposed base64 data only contains [A-Za-z0-9-/\=], though you may have to URL-decode it first. A regex expects to to be passed arbitrary data and most regex libraries can handle binary data, however, a base64 decoder might not expect characters outside of the 64 character set. However, a regex engine could also be compromised, so your mileage may vary. Also, worth considering, regexes are expensive in terms of memory and CPU, so it may actually make it so that your application can handle less requests.

I wouldn't bother doing much validation of the blobs that come out of the base64 decode. Openssl probably has a safer and more correct implementation that anything you homebrew, so long as you...

Patch your dependencies

The openssl library, the base64 library, and anything else in the critical path of parsing user input should be on an aggressive patch schedule (balancing the risk of downtime if you deploy without adequate testing). This includes the php engine, web server, and the operating system kernel. Because most known vulnerabilities will be patch within days, you'll only have to worry about zero-days, which is largely out of your control.

Infrastructure Layer redundancy

External to your question, you could also use a CDN, load balancer, or a WAF to protect against certain attacks or floods. Having a dedicated SSL Terminator can reduce the load on a webserver. Also, rearchitecting your application to operate in independent tiers (or tiers of clusters) can limit the blast radius of a crash and can help you address load. Using a geolocation-based sharding/routing algorithm in a distributed web app can make it so an attacker from a single IP could only DoS other users routed to that shard, so you can ensure, for example, that 67% of users will be up if you have three shards. Botnets can sometimes be addressed by WAFs. This is a huge rabbit hole that probably spans beyond the scope of your question, but hopefully gives you some ideas of directions to look.


Found how to get Oauth2 client_id along matching secret but redirect_uri is whitelisted as requirement. Is it still safe?

Assuming there are no further logic flaws in the OAuth 2.0 implementation (the implementation is compliant with the specification), without chaining your finding with another issue such as cross-site scripting on the white-listed host that allows you to steal the OAuth token, you are right to assume this scenario is not exploitable.

Section 10.6. of the RFC covers this attack scenario in great detail.

  In order to prevent such an attack [authorization code redirection URI manipulation attack], the authorization server MUST
  ensure that the redirection URI used to obtain the authorization code
  is identical to the redirection URI provided when exchanging the
  authorization code for an access token.  The authorization server
  MUST require public clients and SHOULD require confidential clients
  to register their redirection URIs.  If a redirection URI is provided
  in the request, the authorization server MUST validate it against the
  registered value.


How to 'pair' a client/server application securely?

Reinventing the wheel is a bad idea in software development in general, but especially bad when security is concerned. Before (or instead of) designing your own authentication protocol, you should look at existing ones like TLS or Kerberos, understand how they mitigate possible attacks and perhaps even chose an existing protocol to use in your application. You will avoid many common pitfalls, save on development time and your app will have better compatibility, should you want to have it. TLS specifically seems like a good fit to your use case.

By the way, could you explain how displaying a random pin would prevent MitM attacks? Wouldn't the attacker see the very same pin as well?


Opinions on my "Encryption at rest" implementation idea

The only real security issue I see with your approach is that you only seem to talk about encrypting the data -- you do no check that the encrypted data has not been tampered with.  It would possible to modify encrypted data (where you just took a message, applied AES-CBC or AES-CTR mode to the data), where you can guess the form of the plaintext and alter the value (by XORing as appropriate to the block cipher mode to change the corresponding XOR of the plaintext data).  The way to protect against this is to use authenticated encryption modes that combine encryption with a message authentication code (roughly a hash that you can only construct if you know the secret key).

I do see many usability issues from your approach.  First, you lose most of the benefit of using a big database to store information about lots of users.  You can't add or update or modify encrypted information for a user if that user is not logged in (e.g., as is couldn't use this for a messaging system, or for a system that automatically imports information from an external source).  You can't build any indexes, or fast searches, or agreggations, or joins inside your RDBMS that act on data in an encrypted row.  Your database query planner can't plan for the distribution of your encrypted data to execute the right plan.  Data can't be shared amongst users who should be able to access the same information without keeping redundant copies, which goes against the basic rules of database design and will leave you with inconsistent data (as you can only update the information for the current user).

As you mentioned, there's no way to deal with a user forgetting their password without wiping out all their data.  You would need to modify this so this feature is present, as real users will need their passwords reset.  (You can do some sort of system where you store every users key in an encrypted fashion with a strong passphrase protected key).

Finally, this doesn't buy you much extra security.  Any one who gets administrator access on those systems could get access to the protected data if they were a little patient and just waited for the user to login.  They merely log the incoming network requests and capture the user's passwords (at which point they can decrypt the data, either through the system, or from a database dump).  It does not seem significantly safer than having a well developed application sitting on an encrypted hard drive (with encrypted backups), where strict user controls and logging are done at all steps.


Why is Spotify using my webcam (AppleCamera)

I noticed the same thing.
It turned to be the audio driver that enabled some shady/unuseful thing to track your face for audio spatialization. Try to disable this or restore previous driver's version.


Do different files always have different MD5 or SHA1 hash codes?

@PeterHarmann's answer is entirely correct, but to add to it: Secure hash algorithms (which MD5 was intended to be, and which is literally what "SHA" stands for) are supposed to be highly resistant to collisions where any two inputs have the same output. While such collisions will always exist for any algorithm that can take a longer (in terms of arbitrary bits of data) input than its output, finding them is supposed to be near-impossible. Ideally, doing so requires a brute-force attack on an infeasibly large search space, even when utilizing a birthday attack. In other words, while it's true that different files cannot always have different hash digests, in practice it's supposed to be possible to act as though they do.

SHA1 is deprecated because it has been demonstrated to be vulnerable to a collision attack, as Peter's link shows. MD5 is even worse, though; it has been demonstrated to be vulnerable to a chosen-prefix collision attack, where two distinct inputs can have suffixes appended to cause them to have the same hash digest. This was demonstrated as a way to break the protections afforded by cryptographic signatures (one of the key uses of secure hashes) by creating colliding X.509 certificates, allowing an attacker to generate a fraudulent certificate (with their own public key) that has the same hash and therefore the same signature as a valid certificate signed by a trusted certificate authority. The Flame malware used a fraudulent certificate purportedly signed by Microsoft, which was possible because Microsoft had a CA that was still issuing MD5-signed certificates.


Is this DNS reflection attack a DOS or DDOS attack?

I would have answered DDOS since there is distribution (10 attackers).

This is a rather difficult question - one would refer to a thorough dictionary definition of "DDOS", which does not exist.

If you look at "the web", definitions always state that several machines are used for the attack, which is the case here - one could even say that there are 11 machines participating in the attack.


How are passwords stored in the database of a decentralized peer to peer system?

Depending on your goal, you may want to use different architectures:
1. Use a centralized server for authentication
This would be similar to how some videogames act. A centralized server would handle authentication and authorization, but actual data transfer would happen directly between clients for performance reasons.
This approach works well, since authentication can be treated like any other client/server scenario. Passwords can be stored securely in one centralized database, while the server doesn't need to worry about actual traffic between clients.
The downside of this is if your centralized server is unavailable (maintenance, Denial-of-Service attack, obsolescence of service, etc.), then the entire application becomes unusable.
2. Use public-key cryptography
You stated in your question that you do not wish to use PKI. Unfortunately, PKI excels at precisely this kind of scenario. A client can generate a new key pair, which is akin to a new "identity". The client can then publish their public key, allowing others to verify their identity. Whether or not the corresponding private key corresponds to a real-life identity is not an easy problem to solve, but one you don't necessarily need to solve. If a virtual identity (akin to a username/password combination) is enough, then PKI solves this problem well.
Advantages of this system would be that it is very resilient, requiring basically no maintenance, since there is no centralized server involved. Two users, who have each other's public keys, can authenticate each other until the end of days.
Disadvantages is that if you have multiple devices, migration becomes less simple than just "entering your credentials" on the other device. You either need to copy your private key to the other device, or you generate a new private key there and have the keys sign each others public key. In a sense, Key A says "I guarantee that Key B is also me. Yours truly, Key A" and vice versa Key B says "I guarantee that Key A is also me. Yours truly, Key B".
This system works well, but requires your users to be a bit more involved. Depending on who your target audience is, it could be a reasonable assumption to make that your users will understand how PKI works. Otherwise, telling them to copy a file will be something most users can do.
3. Zero-Knowledge Proofs
Basically, you want to prove to someone that you know something, with them knowing anything what that thing is. This seems like an impossible task, but it is doable. Wikipedia provides a set of abstract examples, but for the sake of completeness, I will include one here:

Imagine you have two differently-colored balls, and a color-blind friend. To your friend, the balls seem identical. You want to prove to him that they are differently-colored, without revealing which ball is which color.
Your friend shows you the balls, then places them behind his back and randomly decides to switch them or not. He then asks you whether or not he switched the balls. If the balls are indeed differently-colored, then you can see the difference and say whether or not they were switched.
The first time this is done, your friend believes that there is a 50% chance that you could have just guessed it correctly, so he repeats the task. You succeed again, and now there is a 25% chance it was just another lucky guess. With each repetition, his confidence doubles. After 80 repetitions, your friend is more than 99.9999999999999999999999 % confident that you weren't just guessing, which "proves" to him that you indeed are able to differentiate the balls, even if you did not disclose how, or which ball is which color.

To be less abstract, the Secure Remote Password Protocol implements a Zero-Knowledge Proof, which allows a server to verify whether or not a client knows a password without storing the password. The following image demonstrates the workflow:

Image credit to thinbus-srp
I'll be honest with you, I've never worked with SRP before, but it seems to be something worth looking into.
Why can't I just store hashes?
A password is a so-called "shared secret". Authentication with a "shared secret" works by sending the server my secret, and the server checks whether or not this shared secret matches what the server previously stored. However, in your case, you don't want the involved parties to know the secret - after all, then they could just impersonate you. You're tasked with solving the problem of whether or not someone knows something, without knowing what it is. Let me show you why this doesn't work:

If you just send plaintext passwords, then every client needs to store every plaintext password of every user they encounter - and are thus able to impersonate every user they encounter. Not good!
Just hash them, right? Imagine you "register" with me, telling me the hash of your password is 04C11DB7.... How can you authenticate to me then? You could send me your password in plain text, which means I can steal it. You could also send me that hash again, but then I could just in turn send your hash to other people. By just hashing everything, you made the hash the new password.
Just add more hashes, right? No, it doesn't work. No matter how many layers you apply, I can always just take what you send me and send that to other people.


Implications of leaving admin UI accessible to non-admin users

What would the benefit to an attacker be if they could see client-side code they are not supposed/allowed to use?

It may be easier to exploit vulnerabilities such as CSRF or missing access control if an attacker has access to the client-side code and thus to the requests that may be performed.

It may also be easier to find vulnerabilities such as XSS. Vulnerabilities such as XSS may now also target lower-privileged users as well as higher-privileged users, as both have access to the UI.

  Is having such functionality exposed a really bad practice I should immediately address?

Not really. If it's not needed, I wouldn't expose it though, because of the reasons outlined above.

  If we assume this is open software (and it is, currently, from the employees' standpoint), would hiding privileged users' tools be just some sort of security by obscurity, since an attacker could check the source code anyway?

If it's open source, it's not even security by obscurity, and hiding it isn't strictly necessary (although still not a bad idea, especially because of the possibility to exploit XSS vulnerabilities).


Is any company or group working on secure hardware architectures?

1) Not entirely. 'Secure' operating systems like OpenBSD are secure not only because their code is well debugged and examined closely but also because their default install comes with  very few extra pieces of software in the environment. Its an example of creating the smallest possible attack surface. Anything that the user then adds on top of it is at their own risk. OpenBSD comes with about 20 3rd party packages which are all selected (and some patched additionally) for their strong security.

2) I think what your referring to is known as hardware antivirus. If that's the case, then yes, some companies have looked into it.


Are bookmarklets safe with facebook data?

A bookmarklet is basically a snippet of Javascript that runs on the website. As such, it has access to all your data on the site. Most bookmarklets don't do anything with your data, but it is certainly possible and you should always be careful.


Is there a secure way that a website can retrieve and send your "forgotten" password in plain text

Storing a hash of the password is now the best practice, because even if the password database is compromised, it is not possible for the attacker to get the original password. But if the attacker cannot, it means that neither the site admin nor the application can.

So if the site could send you back your password, it means that it has been stored in plain text or which is mostly equivalent in a security point of view in an invertible encryption. Compromission of a password database normally involves passing multiple barriers, and the last encryption is only one more, not necessarily harder than the other ones: the key must be accessible to the application so it must be present somewhere.

TL/DR: if a site could send you back your password, it stores the password in plain text and not in a hashed form.


How can I figure out what caused the problem?

Basic forensic steps for this type of breach are as follows:

Establish basetime - when did the files that were modified
change?
Use 'find' to search your webroot for files that changed before
basetime but not more than (say) 24 hours before basetime - use
"touch" to create files with the start and end times and use find
with "-newer" and "! -newer" to search within that time frame.  This
might identify any files that were uploaded or changed on your
server as part of the actual break-in.
Now correlate with web access logs to see what happened at the time
those any of those files changed.  It is highly likely the attacker
abused either Joomla or a plugin thereof in order to run code on
your system - for example, at 08:00 they trick a plugin into
uploading a PHP file to your webroot, at 08:05 and 08:10 they access
that newly uploaded PHP file via the web server, and at 08:15 they
use it to execute whatever code went through and modified your index.php.
Once you find any web log entry which identifies the attacker (i.e., accesses a script that you found that was uploaded by the attacker), you can use the
IP address of the attacker to search the logs more comprehensively
and see if you can figure out what else they did.
If you identify any files the attacker uploaded to your system, you
may be able to better understand what they did.  In the last such
system I analyzed, however, their upload was simply a PHP file which
would eval() the contents of the data posted to it - they
essentially set it up so they could submit code to the PHP
interpreter by POSTing to a web page.  This method doesn't leave any
traces of the code they actually ran.

When I say "this type of breach" I'm referring to a watering hole attack, where someone breaks into your web server and injects code into your web files so that you will unwittingly serve them to your web clients.  Such breaches are commonly performed by attacking the web application / CMS / plugins, and while the attacker runs code on your system, they are less likely to use the breach to build themselves a full backdoor or to try and remove traces from the logs - they're just in, modify your files, and gone.

It is very important that you perform the analysis above in order to identify how they were able to execute code on your system; if you don't, they or someone else will just do it again.  Even though the chances are lower that the attacker dove into your system (backdoors, log edits, rootkits) you should strongly consider rebuilding the box and restoring your web content from a clean backup.


Are web browser able to use camera without permission?

The privacy model of modern browsers ask for permissions and sometimes elevated privileges when they require access to the camera. So normally, they are not able to access the camera without your permission.

But there have been multiple vulnerabilities in Flash, Chrome and even Facebook that tricked the user or the browser to turn on the camera.


Remedy for not having filled the disk with random data?

The only information an attacker should be able to extract from an encrypted disk that hasn't had a full random overwrite is an upper bound on the amount of encrypted information on the disk.

To put it another way, a good disk encryption solution shouldn't be relying on an attacker's inability to determine the bounds of the encrypted partition for any security properties.

I agree that filling the disk with data after encryption should yield the result you expect (provided the encrypted partition can dynamically expand to fill the whole disk): all of the data on the disk should now appear to be random (minus partition table etc depending on the solution).


How can it be that I can't register on a website while my VPN is on

It could be that the site that you were trying to connect to blocks VPNs.  There are many sites that do this - Netflix is one that is notorious for this.

It's fairly easy for sites to block VPN's, they just need to learn the blocks of IP addresses that VPN providers use to route their clients' connections through.

For more info, see https://www.howtogeek.com/403771/why-do-some-websites-block-vpns/


A stack canary is still a problem, because you cannot control the EIP in a stack based buffer overflow without overwriting the return address (which is above the carny). Further more the function that contained the stack based buffer overflow must return before the corrupted return address becomes the new EIP.

This is not a problem for dangling pointers.

You need to spend more time with your debugger!  There is no excuse for this.  If you had stepped though exploitation process you would know this!


Try appending a UNION SELECT to the SQL query.

A union-select allows the attacker to add a completely new select-statement. The results of that second select are appended to those of the first. When the first request returns no result, the union-select allows the attacker complete control over the result-set. Remember that a select-statement doesn't even need to mention a table and can return literals instead. SELECT * FROM accounts WHERE username = '' UNION SELECT 'admin', 'TotalyTheAdminsPassword', 'dummy', 'dummy', 'dummy', 'dummy' is completely valid.

A UNION SELECT means that the attacker needs to figure out the number of requested columns (the second SELECT needs to match the column-count of the first SELECT, or the database will throw an error) and which column represents which field, but an attacker can usually figure that out through experimentation.


If TLS compression is not supported is a site still vulnerable to attacks such as BREACH?

BREACH and CRIME don't compromise sites, because they are attacks on clients, not on servers. The server is still involved in that, for instance, TLS compression won't be used unless the server agrees; so that, even if the CRIME attack targets the client, the server can refuse to use compression and this indirectly protects vulnerable clients.

Both attacks relate to the same general principle: encryption hides data contents, but not data size. Compression makes data size dependent on data contents. Therefore, compression can leak information on data contents that encryption won't protect. If the attacker is in a position where he can inject some data of his own along with the data that he tries to recover (formally, a chosen-plaintext attack), then he wins.

CRIME was an application of this concept to TLS-level compression in a Web context. The Web allows for Javascript, that can be hostile and issue requests (subject to some constraints in the case of cross-site requests); this is how the attacker can achieve a CPA situation. Deactivating TLS-level compression fixes the issue, and it was not really fixable in any other way, because the compression-induced data leakage is a very generic concept. Note that HTTP-level compression does nothing for or against CRIME, since CRIME concentrates on the header (the request path and the cookie).

BREACH is another application of the concept, this time on HTTP-level compression. HTTP-level compression is performed only on request bodies, not on the HTTP headers, so BREACH is harder to pull off (while CRIME worked whenever a cookie was involved, BREACH requires the site contents to be amenable in some way to the attack). Disabling TLS compression will do nothing for or against BREACH.

Anyway, compression (be it for TLS or only for HTTP request/response bodies) will be applied by any machine only if it is reasonably sure that the machine at the other end of the connection will understand it -- because of some prior indication to that effect (in the TLS ClientHello message for TLS, in a request header for HTTP). There will be no compression, hence no attack, unless both client and server support it and agree to use it. This is how mitigation for attacks on clients can be applied on the server.


Is this scenario a file upload vulnerability?

First off, you don't have to tamper with the request. Some PHP code could be simply written in EXIF fields or any other metadata field. Or even just bluntly added to the actual binary code of the image before upload.

It means that, in fact, uploading some PHP code is not big deal by itself. I would say most sites allowing image uploads allow it whatsoever. The question is how to activate it.

So to answer your question directly- nope, uploading a php code doesn't make a site vulnerable by itself. What are you looking for is another vulnerability, called LFI, or Local File Inclusion.


Conceptual question regarding signing with Yubikey/Solokey/Nitrokey using GnuPG

GnuPG signatures will sign a digest of a file, not the file itself. When you attempt to sign a large file, GnuPG will create that file's digest (generally by using a hash) and then sign only that.
We can also use the --detach-sig option to show that a (detached) signature is the same size, regardless of the file's initial size:
$ gpg --sign --detach-sig testfile-2M.sig testfile-2M
gpg: using "MYKEY" as default secret key for signing

$ gpg --sign --detach-sig testfile-512M.sig testfile-512M
gpg: using "MYKEY" as default secret key for signing

$ ls -lh .
total 1052792
-rw-r--r--   1 kazwolfe  wheel   2.0M Jul 13 17:33 testfile-2M
-rw-r--r--   1 kazwolfe  wheel   566B Jul 13 17:41 testfile-2M.sig
-rw-r--r--   1 kazwolfe  wheel   512M Jul 13 17:33 testfile-512M
-rw-r--r--   1 kazwolfe  wheel   566B Jul 13 17:42 testfile-512M.sig

When verifying a file, GnuPG will do something similar. It will independently calculate the digest and then verify the signature against that digest.
Encryption works in a similar way. RSA or other asymmetric algorithms are rather slow especially relative to other (symmetric) algorithms like AES. As a result, GnuPG will instead opt to generate a session key that will actually encrypt the file quickly. This session key is then encrypted using the public key.
You can experiment with this too: if you encrypt one (large) file with multiple recipients, the time to encrypt the file won't really change that much as the session key is just being recycled between each recipient.
$ time gpg -r MYKEY --encrypt testfile-512M
       11.58 real        10.43 user         1.08 sys

$ time gpg -r ... -r ... -r ... -r ... --encrypt testfile-512M
       11.83 real        10.55 user         1.17 sys


Is it allowed to store 8-digit BINs outside of CDE

It follows directly from PCI DSS requirement 3.4 that PANs are the defining entity for the CDE system and truncation is the normal mode of storage.

But even if you would store them somewhere which you define not to be the CDE the DSS will still apply to that, as it is a connected system and DSS regulations will apply to the system and processes anyway.

I don't think BINs alone have this problem/requirement, but be very careful I would never extract the  from existing PANs but maintain them from external sources. Especially if you are unsure if they are 6 or 8 digits. (This way it might not be a connected system).


TLS 1.0 JavaScript injection vulnerability (BEAST): what to do client-side?

Until the security hole is closed both ends (web server and browser software) it will be hard to prevent. Unfortunately because the current exploit targets cookies you have minimal control over it client-side. The only exception is to change your encryption ciphers and block or reorder CBC ciphers to the least preferable so it has the least likelihood of being used for SSL/TLS communication.

See http://support.microsoft.com/kb/245030 and http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order-in-internet-explorer-7-on-windows-vista.aspx for how to do this on Windows.

I would suggest that the best thing you can do before a client-side fix is available is education and awareness. Including:

Log out of websites when not in use, instead of just closing the browser.
Don’t save login credentials.
Find out what your trading partners are doing to implement tighter security controls on their web sites.

I guess it also important to note that not all websites using legacy SSL/TLS versions are affected. While the transport security part (SSL/TLS) is, there may be other anti-spoofing techniques in place to reduce the impact of information disclosure.

Stay tuned, be ready to deploy newer browser versions, and no doubt there will be more news soon but hopefully some fixes.


The question is poorly worded but it's safe to assume they're talking about human generated passwords.

  Is my reasoning correct, a wordlist is only useful if there's words in
  the password, and wastes time if there's not?

Using a wordlist can be successful on random passwords, although incremental cracking will usually be more performant.

  I know in John the Ripper there's word mangling rules, what is this?

In my understanding, this refers to leetspeaking words (e.g 'f00tball' instead of 'football'.)

  By the way, are the terms "dictionary" and "wordlist" usually used interchangeably in this context?

Yes.


How is distributed computing security ensured?

Getting fake or skewed results from user-contributed CPU power is a real issue which has no known practical solution, but there are several mitigation strategy:

Duplication. For each given chunk of work, give it to two distinct contributors, and compare the results. This will trap most fraudsters and also computing errors due to bad RAM; unfortunately, this also halves the available computing power. This strategy was what used by some friends of mine who (briefly) got the world record for the N queens problem (i.e. counting all solutions; they computed it for N = 23 back in previous century).
Sampling. This is a variant of the previous solution, in which you duplicate only some chunks, e.g. one in ten (randomly chosen). This will trap fraudsters who game results at least occasionally, while incurring much less overhead. You have to keep track of who did what chunk, so that suspicious values can be removed en masse.
Incentives. If the work is of the find-needle-in-haystack persuasion (like a distributed key cracking effort), then you can announce a grand prize for who finds it. This will induce a lot of potential cheater to actually do the computations, since not doing them means that they will not get the prize.
Fully Homomorphic Encryption. That one is a generic solution, but the best known algorithm for FHE has the inconvenient drawback of incurring some overhead which is counted in billions -- i.e. even if the whole Internet contributed to the computation with FHE, it would not match what you could achieve without FHE on a single PC.
Obscurity. The all-time favourite of anti-cheating strategies: simply don't show the source, keep the protocols secret, and hope for nobody to bother running a debugger and doing a bit of reverse-engineering. In a similar scenario of distributed computing, namely online games, it does not work well.
Luck and trust. Simply pray that there will not be too many fraudsters, and that most chunks will be processed as they should. Depending on the type of computation, this may be a valid strategy. For instance, it may work for a key cracking effort, since a few skipped chunks will not matter (unless the key is in one of them, which would be bad luck but improbable if most contributors are honest). It would not work for a complete counting where you add all the results (each wrong value will alter the total).

Historically, distributed.net encountered such issues in their DES/RC5 cracking efforts. Some people would fake results, i.e. alter their clients so that they responded "job done, no key found" without doing the computations; the gamed clients would respond faster than clients which really do the work. They were doing that just to be at a better rank in the list of contributors, ordered by CPU power (retrospectively, it was quite obvious that computer owner would act just like car owners do). Their response was an obscure client without source, which was sufficient in that case (too few people did the reverse engineering to cheat again).

There is also the dual problem, i.e.: how do you make sure, as a contributor, that the client code they send you is really benign ? This is not an easy question, and it is made harder by closed-source client code...

Linux includes a nifty system call named seccomp() which could be useful for that. And, at least theoretically, this might not be sufficient for complete isolation of a potentially rogue process, because that process will share caches (L1 cache, jump prediction...) with other processes, and it has been demonstrated to be usable (in lab conditions) to recover an encryption key.


The security of sending emails with SPF/DKIM, but not signed

SPF on your domain is not about preventing you from sending forged emails; it is about preventing other people from sending emails with your domain. To be more precise, if you own domain foo.com, you can document in SPF that "every email which purports to come from an @foo.com address should exit from machine smtp.foo.com and none other". Email servers who receive an email with an alleged sender with an @foo.com address may then lookup the SPF records and check whether the email seems to come from the legitimate server (yours) or some other.

SPF processing is not mandatory so it is up to each email server to enforce it, at their leisure.

The SPF records on your domain (foo.com) will not prevent you from sending an email with a fake address, e.g. an address ending with @bar.com. In that case, it would be the SPF records on the bar.com domain which matter.

DKIM has a somewhat similar goal. When your server uses DKIM, then it signs every email that goes through it. The DNS for your domain documents that fact, and publishes the public key (the one used to verify the signature). Supposedly, when an email server receives an email with an @foo.com sender, that server will see your DKIM key in the DNS, and thus verify the signature. If the signature is absent or does not correspond to the mail contents, then the receiving email server will know that something is amiss.

There again, DKIM processing is up to each email server. And, there again, nothing in your domain will prevent you from sending emails with @bar.com as alleged sender -- but if the bar.com owner uses DKIM himself, your forgery will be revealed.

Summary: the DNS rules related to SPF and DKIM, added to the domain foo.com, document how an email should normally be sent/signed when it pretends to be sent by someone with an @foo.com address. The DNS rules in foo.com tell nothing whatsoever about emails which claim to originate from another domain.


This is how it's done.
Go to some site, let's say facebook/netflix .
Check out the cookies that the site uses to authenticate you, you can edit the cookies from the dev tools! just mess around with them, edit them until you refresh the page and you are logged out, try to figure out what are the cookies that hold your session ID.
In facebook's case the cookies that are required are called "c_user" and "xs"

if you open a diferent browser (say firefox) or a diferent computer and paste those cookies while you are on facebook's domain using the dev tools, then you will be able to resume your previous session, that's session hijacking
You can add cookies on firefox on the development tools, under storage, by pressing that Plus button.

Facebook might complain, because it will see that you suddenly changed the user agent (or some other way of fingerprinting who you are) and will likely send you a notification asking about "suspicious activity" on your account.
The "cookies" file  you mention is a SQLite database that contains ALL these cookes, you can open it with sqlite browser and check them out yourself. The actual values of the cookies have been encripted in recent versions of chrome, so they cant be viewed from the sqli database so easily.
A few ways of getting the content of cookies from someone else are:

If the cookie is sent over HTTP instead of HTTPS and you are in a shared wireless network, you can sniff the traffic and get the cookie

If the cookie is not marked as HttpOnly then it can be read by javascript, if you can add some javascript to the site (this is called Cross site scripting) then you can read the cookies content and ask javscript to send that to some server you control.

After you have the cookie, you just insert it into the browser as shown above and you are done.
Usually important cookies are marked with the parameters

secure - It can only be sent over HTTPS
HttpOnly - It can only be used on requests, javascript has no access to it

So they are much harder to steal.
For more information on cookies you may want to read Their specifications
Edit: just realized that this question is so old. for some reason it appeared on the site's front page.


Is it possible to hack WPS PIN of routers that lockout exponentially after failed tries?

This is happening because your AP is able to filter out the MAC address and block it after an x amount of requests. What you need to do is to change the MAC address every x requests so the router won't be able to lock you out.

Use reaver mac address changer: Reaver -i mon0 -c x -b xx:xx:xx:xx:xx:xx -vv --mac=vv:vv:vv:vv:vv:vv

Warning: This might crash your router do to an overload of requests...


EncFS vs EFS advantages for Dropbox-seamless encryption

I had the same problem ~2010-2012 and never made it work.

EFS - normal users (and programs, such as dropbox client) does not have access to ciphertext, OS either decrypts file automatically or refuses to do anything with it. It seems that the only way to access ciphertext is by some method intended for backups. (as this cannot work theoretically, did not tried experimentally)
EncFS - (assuming on windows), back then it did not work properly at all. Files became corrupted on modification. If it works properly now, it might be the best option.
Bitlocker - (i actually tried truecrypt, but there are the same problems). It was the only thing that somehow worked, but on changes syncing meant transferring entire file. I know, that it was supposed to sync only changes, maybe smallest syncable unit was entire file?


Can you create an OpenSSL certificate with non-English field values?

It is possible to create OpenSSL certificate with non-ASCII characters by using the -utf8 option.

In order to get a certificate for a public key, you create a Certificate Signing Request (CSR) that contains the information to be certified, such as the Distinguished Name and Common Name, Organization, City, State, Country and Contact information.

When creating a CSR, OpenSSL interprets any text you enter as ASCII. If you try to enter non-ASCII characters (such as Chinese), the certificate will contain 'random' characters rather than the text you tried to enter.

However, it is possible to change this behaviour using the -utf8 option (see OpenSSL Wiki):

openssl req -new -utf8 -newkey rsa:2048 -sha256 -out csr.pem

In this case, the information entered is interpreted as UTF8, allowing you to enter Chinese characters in the interactive dialog asking for the Common Name, State, City, etc.


Why did I get a wrong IP and certificate for www.facebook.com just now?

Sounds like either your router or your ISP's DNS server was hit by a DNS cache poisoning attack. The following article describes how this might occur: http://www.networkworld.com/article/2277316/tech-primers/how-dns-cache-poisoning-works.html

Because this only is able to change the configuration for the Time To Live (TTL) of the domain being hijacked (facebook.com), it will go away of its own accord once that time has expired, unless the attacker is able to repeat the attack.

You may want to configure the systems on your network as well as your router itself to consult a (more or less) trusted public DNS server in place of those provided by your ISP. One example is Google Public DNS at 8.8.8.8 and 8.8.4.4.


How does having a custom root certificate installed from school or work cause one to be monitored?

I was reading an article which said that if you install custom root cert from a third party then they can decipher all communication between you and others.

I have no idea what you were reading (citations would be helpful). But you are right in that it is not sufficient to just have a custom root CA certificate installed as trusted - the school/work also has to be an active man in the middle in the traffic and use this CA certificate for SSL interception.

So either by installing malware on the computer or monitoring internet traffic.

Not only malware installed on the computer can monitor the traffic. It is actually common that trusted programs like antivirus or parental control software do this.
And when being directly inside the company (or school) network the path to the internet is usually through the companies firewalls and proxies anyway. Even when connecting from remote with a VPN or other access software the traffic  is routed and inspected through company controlled firewalls/proxies, either in the company directly but more often also somewhere in the cloud.


Can KRACK be used to obtain wifi credentials that could be used to normally connect to an AP?

An adversary using KRACK can decrypt information that is transmitted via WiFi that should be encrypted. This can only be done after a victim is authenticated to an AP. Read more on how the actual attack works here. So no, it is not possible to obtain the credentials.

However: if you were to change the password of your AP while an adversary was reading your traffic, s/he could also read the new password, if the connection to your router is not protected by another form of end-to-end encryption.


OMAC: multiplication in a finite field - how can I compute the correct polynomial

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


Are setuid executables not allowed to use swap?

When programs want to mark a specific area of memory as must not be swappable for performance or security reason, they can use mlock() system call or mmap() with MAP_LOCKED. Note that mlock()ed memory can still be written to disk if you suspend to disk (a.k.a. hibernate); to be able to securely suspend to disk, you would need to set up encrypted swap and/or full disk encryption. Also, while core dump is often disabled by default on many distros, if you enable core dump, mlock()ed memory can also be core dumped, program can use MADV_DONTDUMP or coredump_filter to tell the kernel not to include certain memory from the core dump.

I can't find any reference anywhere in POSIX setuid() manpage or Linux setuid() manpage that specified that setuid program is automatically not allowed to swap.

The closest sentence that might resemble the book's claim, from Linux setuid() manpage, is "If uid is different from the old effective UID, the process will be forbidden from leaving core dumps."


You are performing an NMAP scan from inside the network. Just because these ports show as being open internally, doesn't mean they show as being open outside of the network.

Grab your external IP and run an online port scan - this will give you an idea of what ports are open to the world, or a potential 'hacker'.


Is SSL/TSL and HttpOnly enough to be sure that a session cannot be hijacked?

Those are the must dos, and they offer good  (but not perfect) protection. See question four.

  Is there a way to use client IP addresses as an extra layer of protection?

Just checking that a session ID is used by the IP that created it will break your site for a lot of users, e.g. for mobile users who might not have constant IP:s. (It will also not protect users if the attacker is on the same LAN and share the users IP.) This is not recommended.

What you could consider is using geo location. If a session ID created for a user in Mexico suddenly is used by someone in China five minutes later it might be a sign that something is wrong. On the other hand, this will break things for people using Tor and some VPN:s that rotates IP:s.

  Are there any more measures that can be taken to protect a session?

Yes. Make sure that you generate long, random session ID:s with a CSPRNG.

Also, make sure you are not vulnerable to session fixation by not accepting session ID:s you have not generated yourself and/or changing the session ID on login.

  Can we ever be 100% that someone cannot hijack a session?

No. You can never be 100% sure about anything regarding security (or anything at all, for that matter). For instance there is no way you can protect your users from someone with physical access to their computer, since that would allow the attacker to just read the session ID from the cookie in the browser.


Win server 2003 sp2 'local' Privilege escalation via thin client

Windows Server 2003 SP2 is out of MSFT's support lifecycle.  Microsoft requires your server to be at SP3 in order to be eligible for security and other hotfixes.

Mainstream support for Win 2003 SP3 ended 7/13/2010.
Extended support ends 7/14/2015.

Your server is vulnerable all the security patches that SP3 fixed.  Of course your deployment mitigates this somewhat.
http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=windows+server+2003+&Filter=FilterNO
If the SunRay thin client issues an RDP call to your server, and the ethernet cable to the thin client is disconnected and placed into a laptop (etc), then the RDP could be exploited.  There are several known issues with unpatched RDP.
There are also MITM issues with Win2003 RDP if the attacker saw an administrator log in from another machine.


Serving image from outside web server root

Yes, saving the files outside of the web root will reduce your attack surface for direct object references.   I would also recommend doing the following:

Validate the file when uploading - Check the mime-type of the file
against a whitelist of valid image types.  Also, check the mime-type
of the bytes uploaded.  Don't rely on what the browser told you the
file was.
Give the file a random name -  You can append a
    timestamp to the end of the filename if you're concerned about
    uniqueness.  If the user is able to upload a malicious file, a
    random name will make it harder for them to reference that file and
    have some webserver process execute it.
Don't search for the file based on user-controlled input.  This can leave you open to path traversal/more direct object reference (specifying another file, which they should not have access to.) issues.

The major attack vector that having a file upload can enable is local file inclusion aka. running arbitrary code on your sever.  This could include running arbitrary php code and updating the javascript files.  It could even result in the server itself being compromised depending on the permissions of the user account that your webserver is running under.


Icesword rootkit detector, How does it work?

tl;dr - compare the results of two functions that do the same thing, and look for differences.

Instead of focusing on that single rootkit scanner, I'm going to talk about generic techniques that rootkits use and how we can find them. This should give you a better overview of the challenges involved.

Rootkits work by intercepting certain system calls and modifying their parameters or results. It's difficult to explain how a rootkit finder works without explaining how hooks work.

For example, on Windows, a call to CreateToolhelp32Snapshot creates a snapshot of the current running processes, and stores it on the global heap. The Process32First and Process32Next functions then allow the application to iterate through the list of processes.

Here's a quick example:

PROCESSENTRY32 proc;
procList = CreateToolhelp32Snapshot(flags, 0);

Process32First(procList, &proc); // seek to first item in list and store it in proc

do {
    printf("Process ID: %d\n", proc.th32ProcessID);
    printf("Thread count: %d\n", proc.th32Threads);
    printf("Path: %s\n", proc.szExeFile);
    printf("-----\n");
}
while (Process32Next(procList, &proc));

Now let's imagine we want to hide a particular process from the list. There are two main ways to do this: in usermode and in kernelmode. The first (usermode) is to hook the Import Address Table (IAT) of the process we want to spoof, i.e. the process we don't want our hidden process to be seen by. There are other ways, but this is the simplest to explain.

When you compile a program, the executable contains a list of imports, which consist of the name of the DLL you want to import from, the name of the API within that DLL, and its Relative Virtual Address (RVA). This is all stored in the import directory, which you can view with a tool such as PEInfo.

When the program is executed, the executable file is loaded into memory. The kernel looks through the import list and identifies which DLLs need to be loaded into memory, and which are already in shared memory. Once that's done, it finds the addresses of the imported functions in memory (either by RVA or name) and writes those addresses over the RVA values in memory. The result is that the IAT acts like a big jump table to all the imported APIs, so the program can run instructions like call [addrOfIAT + n*4] to call the nth API in the table.

If we replace the addresses in the IAT in memory, we can make the program call our own code instead of the API. In this case, the easiest way to hide a process is to hook Process32First and Process32Next. If we parse the executable's headers, we can find the address where the IAT will be loaded, and the offset of the APIs in the IAT. Once we know that, we can hook the IAT. There's a bunch of ways to do it - directly writing over the IAT memory, inject code to do it, or inject a DLL. Doesn't really matter how you do it, and it's outside the scope of this answer. The goal is to copy the address from the IAT, then overwrite the address with that of your own code. In this case, let's imagine the following pseudo-code:

void* Process32FirstOriginal;
void* Process32NextOriginal;

const int HiddenProcessId = 1234; // ID of the process we want to hide

void InstallHook()
{
    int offsetP32First = 0x40; // offsets in the IAT
    int offsetP32Next = 0x44;

    // make a backup of the actual API addresses
    // this isn't actually how we'd access the IAT, I'm just being simplistic
    Process32FirstOriginal = IAT[offsetP32First];
    Process32NextOriginal = IAT[offsetP32Next];

    // patch the IAT with the address of our hooks
    IAT[offsetP32First] = &Process32FirstHooked;
    IAT[offsetP32Next] = &Process32NextHooked;
}

int Process32FirstHooked(void* snapshot, PROCESSENTRY32* proc)
{
    // call the original function
    int result = Process32FirstOriginal(snapshot, proc);
    // did we just fetch the process we're trying to hide?
    if (proc.th32ProcessId == HiddenProcessId)
    {
        // skip the process we're trying to hide and get the next one
        result = Process32NextHooked(snapshot, proc);
    }
    return result;
}

int Process32NextHooked(void* snapshot, PROCESSENTRY32* proc)
{
    int result = Process32NextOriginal(snapshot, proc);
    if (proc.th32ProcessId == HiddenProcessId)
    {
        result = Process32NextHooked(snapshot, proc);
    }
    return result;
}

So what are we doing here?

Implement wrapper functions for Process32First and Process32Next that skip over the process we're trying to now.
Get the addresses of the original functions from the IAT.
Overwrite the addresses in the IAT with those of our hooks.

What this means is that when the program tries to call a hooked API, it really calls our hook. Our hook then calls the original function and manipulates the results.

So, how does a rootkit detector find these hooks? There are a few ways:

Iterate through each process's IAT in memory and compare the addresses to those that should be there, according to the import table in the executable file. Downside of this is that, if the rootkit detector itself has had its IAT patched in memory, the rootkit could simply manipulate the results of the memory and file reads functions.
Use non-standard APIs to iterate through processes, read memory, etc (e.g. ntdll functions). This will work as long as a usermode rootkit doesn't patch these.
Implement a kernel-mode driver to iterate through processes and perform other checks, then compare the results to that of a user-mode scan. If stuff is missing, something is manipulating the user-mode side of things. This will successfully detect almost any user-mode rootkit.

Now comes the second type of rootkit: kernel mode. In this case the rootkit does almost exactly the same thing, except it hooks the System Service Dispatch Table (SSDT) instead of the IAT, which services user-mode to kernel-mode calls. The SSDT is basically the same as an IAT, except it contains the address of every kernel-mode API. The rootkit simply hooks the kernel APIs responsible for servicing the CreateToolhelp32Snapshot call, filtering out the process that it wants to hide. This stops normal discrepancy scanning from working, because the results the scanner sees are hooked too.

So, how do we scan for kernel-mode rootkits? The answer is: it's difficult. If the rootkit is hooking the SSDT, we can't rely on it. So, we have to resort to implementing our own versions of the kernel API to read and manipulate kernel objects. This is called Direct Kernel Object Modification (DKOM). This is tricky, since these objects are usually undocumented or only partially documented, and may change between versions of Windows. Processes in the Windows kernel are represented by EPROCESS structures, in a doubly linked list.

// get the EPROCESS struct for the current executing process
EPROCESS* eproc = PsGetCurrentProcess();
// get the LIST_ENTRY item for the EPROCESS, so we can iterate the linked list
LIST_ENTRY currentEntry = eproc->ActiveProcessLinks;
// store the first pID, so we know when we've looped the list
DWORD startPID = (DWORD) eproc->UniqueProcessId;
int count = 0;

while(1)
{
    // find the EPROCESS structure from the LIST_ENTRY object
    eproc = (EPROCESS*)((DWORD)currentEntry - OFFSET_LIST_FLINK);

    // are we at the end of the list?
    if (count > 0 && eproc->UniqueProcessId == startPID)
    {
        // we've gone through the whole list!
        KdPrint("END\n");
        break;
    }

    // print the process ID to the debugger
    KdPrint("Process ID: %d\n", eproc->UniqueProcessId);

    // go to the next entry
    currentEntry = *currentEntry.FLink;
    count++;
}

We can then compare this list of process IDs to a list produced by normal kernel-mode and user-mode APIs, to find out which processes are hidden and where the hooking has been done.

Unfortunately, malware has the same ability to do this. They can remove the EPROCESS of their hidden process from the list:

void HideProcess(EPROCESS* proc)
{
    LIST_ENTRY hideEntry = eproc->ActiveProcessLinks;

    // get the previous and next list entries
    LIST_ENTRY prevEntry = *hideEntry.BLink;
    LIST_ENTRY nextEntry = *hideEntry.Flink;
    // set their forward and backward links to skip over the hidden entry
    prevEntry.FLink = &nextEntry;
    nextEntry.BLink = &prevEntry;
    // set the hidden entry's forward and backward links to itself
    hideEntry.FLink = &hideEntry;
    hideEntry.BLink = &hideEntry;
}

This effectively removes the process from the list, making our previous DKOM approach to scanning impossible.

From here, the only approach we can do is an arms race of artifact scanning. This involves identifying kernel objects that have latent references to hidden objects, in order to identify them. Alternatively, we can scan through memory for objects that look like EPROCESS entries or other kernel objects, in order to identify unusual values. SSDT hooks can be identified in this way, by looking for the real APIs in memory (scan by signature) and comparing their real addresses to the addresses stored in the SSDT.

Hopefully this gives you a more comprehensive understanding of how rootkits work, and how we can look for them.

Further reading:

Rootkit Arsenal - Rev. Bill Blunden (where I learnt most of this from!)
NirSoft Vista Kernel Structures
Hooking on Wikipedia
Hiding SSDT hooks (PDF)
Windows Driver Kit (WDK)
When Malware Meets Rootkits - Symantec (PDF)
Rootkit DKOM at Blackhat - HBGary (PDF)


Why are ‘unsecure networks’ still a thing in the age of HTTPS?

You are confusing HTTPS with network security. And, in the more general sense, encryption with security. Encryption only deals with confidentiality and integrity. Availability is usually recognised as part of the Security domain(1).

Not all network traffic is HTTP or HTTPS. Even HTTPS (usually) depends on:

DNS - which has no inbuilt protection (2)
Wetware compliance

There are still a lot of other protocols in common usage where use of encryption is not available / optional / hidden.

You also only consider your TOE as the client. Even if the TOE is only a browser, the days when this exclusively acted as a client are numbered. Certainly the client host will already be running many services which may be accessible from the network - and the "trusted" network should be one which provides some control over the access to these services. It is worth noting that where more resource is devoted to securing the network, this is often coincident with exposing more of the internals of the potential target devices by management and security services.

  but as long as they don’t get any more information I’m fine with that

A lot of AshleyMadison's customers were not fine with their use of the site being made public; we cannot tell you what level of security you require.

  And most HTTP websites...so hardly sensitive stuff.

An SSL stripping attack needs to start on a non-SSL page

The internet, and computer security is not bounded by your personal experience / knowledge.

1) Really "security" is a rather abstract collection of a lot of the elements of providing a service. ITIL, for example, at the highest level separates the utility of a service into Performance, Capacity, Functionality, Security and Availability (i.e. treating availability as a separate entity).

2) There is an alternative protocol - secureDNS - which has some protection


Why would a virus writer bother to check to see if a machine is infected before infecting it?

The goal of most malware is to remain active as long as possible. The longer it can collect keystrokes, participate in DDoS attacks, redirect search results, send spam emails, shows popup ads, etc., the more profitable it is for the creator. To reach this goal, it has to be undetected.

If a piece of malware infects a machine twice, it may leave the machine in an undefined state, or cause conflicts. It may also eat up more resources than normal. This can lead to detection through a variety of operations:

Attempting to lock the same file twice, causing a crash.
Injecting into running processes twice, causing memory corruption and crashes.
Infecting the same file twice, causing it to be corrupted.
Attempting to install multiple hooks on the same APIs / objects / system messages, causing erratic or undefined behaviour.
Increased CPU, network and disk usage from the burden of having multiple copies installed.

The less resources used and the less disturbance caused, the less likely the user is to notice something is wrong. Once a user notices something isn't working properly, they'll try to fix it, which might result in the malware being removed. As such, it's better for the malware creator to prevent these problems and remain covert.


What tools and techniques do we have at disposal to manually search for rootkits?

By the definition of rootkit they likely have full control of your system all the way down at the lowest levels, and therefore any commands you run to "check" for a rootkit may themselves be compromised and returning you faulty data.

Traditional ways may be to hash every file on the system and diff them with a known good system and see what system files don't match.

A lot of things happen in memory now though so you may need to do a memory dump and compare the contents of currently running processes and libraries with known good copies ... and comparing what is in memory for a process to what is on disk for that same process.

Also at a driver or boot level similar validity checks may need to be performed.

Another option is analyzing network traffic leaving the system and seeing where it's coming from. For example, if Windows Explorer is talking to Russian IPs you may have found your rootkit.

In summary though if a rootkit is found or suspected there is generally no 100% solid way to remove them ... instead the system will likely need to be rebuilt.


How are TLSv1.0 ciphers negotiated as TLSv1.2?

No, new versions of TLS have not removed cipher suites defined in older versions.1 Which version of TLS you use and which cipher suite you use are two linked but separate matters (you can't always use a new cipher suite in an old TLS version). OpenSSL is just listing which version the cipher suites were first added in.

The PRF is mostly used for key derivation (and verifying the handshake hasn't been tampered with). TLS 1.0 and 1.1 said, "we do this thing with MD5 and SHA-1". TLS 1.2 went and changed it to, "Yeah, so, now it depends on the negotiated cipher suite. All the old cipher suites will now use SHA-256, btw.". (Edit: I'm 99% certain that's correct. The old cipher suites may use either MD5 or SHA-1 instead. The RFC confuses me.)

1 The agenda for TLS 1.3 includes removing all sorts of old, obsolete nonsense, including many yucky cipher suites. Also, I'm being careful with my language when I say "TLS". I'm ignoring SSL. SSL 3.0 probably removed stuff, and I don't know if TLS 1.0 did.


Kernel32.dll , Kernelbase.dll and Malware

CreateProcessInternalW is not part of the "public" API exposed by Windows.  Consequently, Microsoft is free to move it or reimplement it how they see fit.  (Including removing it entirely, unlikely though that may be.)

Starting with Windows7, Microsoft started building something that they called "MinWin", which is the minimal set of Windows DLLs & Kernel necessary to create the core of the OS.  (Probably intended for containerization or standardizing an embedded core.)  This lead to the creation of KernelBase.dll, which contains the MinWin functionality for Kernel exports.  Many functions in kernel32.dll are just stubs that call their partner function in KernelBase.dll.

I'm not in front of a Windows 10 box right now, but I would guess that CreateProcessInternalW moved to KernelBase.dll as part of this, and so consequently the malware developer is looking for it there in Windows 10.  (Perhaps kernel32.dll no longer exports the symbol.)


The scenario you have provided is still 2FA and not 3 (as your question states). This still only uses something you know and something you have to authenticate. Now, moving on to why a pin and password would be needed. You are right, in that asking both doesn't increase the 'number of factors'. I have seen some companies not use the password, and just ask for the username and PIN + RSA code. But, if the PIN and the password were to be stored in two different data stores (2 different DBs, regions etc), compromise of one still wouldn't be enough to crack one of the two factors needed to authenticate.


On software encryption vs hardware encryption, read this comparison on Kingston's website, and your choice may be easy, but this is marketing language.

I'm quite sure that Open Source software encryption like GPG is more secure. See this question: Is hardware based disk encryption more secure that software based?.

The basic question is: from who do you want to be protected? The NSA? Hardware will not work. They can probably read the encryption key from the chip. Software will not be safe without a good and long password. However, when the disk is stolen, most people will just erase it, and in that case it will protect you good enough.

If one of your friends wants to copy your data, he has probably better ways to get there, like installing a rootkit or something.

The WD disk seems to be OS friendly. See this review.


Different certificate information for the same website?

It looks like anobii.com are making use of a content distribution network CD Networks.  Visiting that page the SSL certificate for static.anobii.com is goes to support5.cdnetworks.net.

So the main content is being served with an ordinary certificate but some of the other content is being served with an invalid certificate, which is what I think is causing your error.  what's interesting is that firefox doesn't alert if you go to the main page, but if you pick a resource on that page which is being served from CD Networks and browse directly to that (e.g. https://static.anobii.com/favicon.ico ) you get an SSL warning as below

As to why Dolphin is warning you and firefox isn't, my guess is that it could be difference in how they handle SSL warnings


An ad seems to be downloading malware into my epub file

You might want to rethink your use of DailyUploads. When I tried to get to it, Chrome warns me off saything that it is compromised - undoubtedly why you are getting inserted malware.

As such it seems very unlikely that it is safe to go there at all let alone with adblocking disabled.

Any site that disallows adblocking should be avoided if at all possible. There are far too many rogue adverts around that can bypass most protections.


Should IBAN and bank details be considered private data and encrypted?

As a European, I consider my IBAN to be my private information, just like my email address, real name, home address and IP address. I'd like for you to not store any of them, but if you have to, please encrypt them and make sure my information (it's my information, not yours) is secure.

So to directly answer your question, yes, encrypt it and don't  store the key nor handle encryption/decryption on the server processing user requests.


What is more secure: Many subdirectories, or many subdomains?

Neither is necessarily more secure, but I will give you some opinions and perhaps facts.

Host-extract can determine hostnames, which is also possible via virtual host enumeration.

DirBuster, skipfish, and fuzzdb can rely on forced browsing, directory indexes, and predictable resource locations to find vulnerable directory structures and other issues. Spiders and crawlers can traverse directories, and certain ones can also traverse hostnames (I know that skipfish is capable of this).

In some ways, virtual hosting is more difficult to manage (you mentioned SSL, which is a great point). If this is easy for you to manage, it may end up being more secure because of the ability for directories to leak much more information than hostnames, and to be vulnerable to attacks such as XSS much more easily (as @Rook describes in his answer).

I prefer to at least separate out sites (by hostname) which contain behavior (e.g. Flash, Ajax, Javascript libraries, RIA frameworks, dynamic pages, etc) versus ones that contain formatting or static content (HTML, CSS, XHTML, non-dynamic pages). I think it's also good practice to separate out SSL domains from non-SSL domains. The reason here is because you can provide more stringent controls around contextual-escaping on SSL/TLS hostnames than you would on non-SSL/TLS hostnames. If you separate out Javascript from CSS from HTML, then you know which contextual-encoding must take place on which hostnames as well. I have more suggestions about how to handle XSS in this post where I mention to not build HTML on the server and other tidbits.

Usually this is never up to a security professional, or security team. It's up to the developers, marketers, and SEO experts. They decide what gets a hostname or a URI structure. I will research into this topic further and update my answer as I get new information. It's an interesting question.