RSA decryption is slow compared to encryption as d the private exponent is necessarily large, while (with proper use of RSA) there's no reason the public exponent can't be chosen to be small like 65537 (or even 3).

RSA encryption generates the ciphertext by m^e mod N, where (N, e) are your public key and decryption works via c^d mod N where (N, d) are the private key which is calculated efficiently when you know p and q the large primes.

Here's an example of a key I just generated.  To keep the example simpler, I only used 256-bit RSA (weak), in reality you should use at least 2048-bit RSA these days, in which case have p, q, N, and d will each have eight times the number of digits.  (Meanwhile e will stay 65537 even with 2048-bit RSA.)

p = 255972651020913583852708738755558492779
q = 315961372360286283221530569994994089667
N = 80877470103268491690225776687889776985485516372419877405296906209811698014593
e = 65537
d = 62101042930507606982857645825838676738862341745400679479964616076341592694761

You can check that the RSA conditions are satisfied, p and q are prime, N == p*q, and e*d % ((p-1)*(q-1)) == 1 (this last condition is what allows RSA decryption to work via Euler's theorem ).  You can also test that encryption works -- for a message m = 12345678901234567890, then c = m^e mod N is c = 37526865766319703630750491158429044860161927049301804846356525193422406944367 and then c^d mod N will be 12345678901234567890 (no wolframalpha link -- input too long for free version).  Here's a ipython notebook demonstrating all the steps -- note in python pow(x, y, N) is the syntax for x^y mod N.

From this it appears quite obvious that the time to calculate m^e mod N will be a much quicker calculation than c^d mod N.  For encryption, exponentiation by 65537 by repeated squaring will require squaring and taking the modulus 16 times with one additional multiplication as m65537 = m * m216 (its 16 squarings as x2n = (x2)2n-1).  For decryption with RSA-256, exponentiation by d will require squaring 256 times and about 128 (the number of 1s in d in binary excluding the first 1) other multiplications with RSA-256 and for each squaring you need to also calculate the modulus of N.  It should be noted that these modulo multiplications of large numbers is not a constant time operation but depends on the bit-length of the numbers.  Note if you chose d to be small like e then your private key could be brute forced (encrypt a message using the public key, and then try every small value of d until it decrypts properly).  Even if d is too large to brute force in this trivial manner, attacks on small d (meaning d < N1/4/3), then there are more sophisticated attacks that will allow an attacker to discover the private exponent.

(And yes, I ignored some real world RSA facts.  You can use Chinese remainder theorem by using p and q as part of the private key to speed up decryption.  Also, you do not use RSA on the actual message, you need to use secure padding (OAEP) and then only encrypt a random symmetric key which is then used to encrypt the actual message).


What risks are there with a Bluetooth based door lock, and are there any mitigations?

Very interesting Technology Indeed

If the technology is designed, developed and safely, then it can be fairly secure. It seems to provide a lot of cool features.

Configure keys to access house centrally on "App".
Deploy "Key" to person as needed and for agreed timeframes and without physical delivery.
Decommissioning keys as needed.
Many keys possible, named and configured and reported.
Bluetooth wardriving might be possible, but can be minimised/eliminated by system provider.

BUT: It introduces additional risks

The Key System provider has full control and access to your home.
The Key System provider must stay in business to continue to use the locks.
Internet access can be actively disrupted and stop certain features from working (wipe/disable of keys)
Design bugs in the system (not enough information on site to tell).
Implementation bugs in the system, includes their web systems (may allow complete access to attacker).
If important: Government can access your home surreptitiously.
Denial of Access to home: System fault or bluetooth radio could stop ingress or worse egress from house (Think about how you would access you home if the key system was inoperative, remember that the key will not be pickable by a locksmith).
Remote or physical compromise of any phone with keys could compromise your house.


How to prevent CAS from leaking user identity to arbitrary visited websites?

Disclaimer: I don't know CAS, but I think I understood what it does and how it works.

Your attack scenario is not possible this way - even if the corporate website would not have frame busting headers. These frame busting headers are more to avoid click-jacking, but that's another topic.

If the frame does a redirect, then only the frame content is redirected.

The evil site cannot access the anything of the frame it embeds (not even the URL), because it's in another site. If it could, then such scenarios would be possible, but all modern browsers (even since IE4 I think) disallow cross-site access, so the evil site cannot access the new URL and therefore has no access to the identified user of the IFRAME.

As a user you can protect yourself by always logging out and if any suspicious site asks for permissions, don't authenticate.

A good example of this scenario you mention is Facebook. Many sites embed Facebook commenting functionality and other stuff. But they don't get your user name in any way. If it would be possible to get the Facebook user name somehow (Facebook users rarely log off) then this would be a big security hole. You could apply for the bug bounty if you'd find a way to get it or to log on and post or vote in the name of the user.


HMAC/PBKDF2 vs Simple hashing algorithm for web service authentication?

Recommended approach. I recommend that you use SSL and authenticate the client using their password.  Then you won't need any fancy MAC, hash, PBKDF2, etc.

Details.  You asked how to authenticate the user.  Here is a simple approach.  Use SSL sitewide.  When the user logs in (entering their password in via a web client), then set a session cookie that remembers the user for the rest of their session.  (Make sure to use SSL throughout, and to set the secure flag on all cookies.)  If you want, you can set a persistent secure cookie once the user authenticates, so they will never need to enter their password again on this browser.

If you want to access the web service from a dedicated mobile client, the same approach works fine.  The web server can send a secure persistent cookie which the app can store permanently in its app-local storage, and can use that cookie to authenticate the client.

Alternatives. If for some reason the above is not possible, there are some fallback alternatives, but I think they are less preferable and more likely to have security problems.  Here's one plausible fallback method:

On the first launch of your mobile client app, it prompts the user for their password, connects to the server over SSL, and sends the password over SSL.  The server responds with a random 128-bit authentication key (chosen by the server using a crypto-strength PRNG).
The client app stores this auth key permanently in app-local storage.  The server remembers the association between this auth key and the user's account permanently.
All future requests from the client app are authenticated using this auth key, as follows: you append a parameter to the end of the URL that holds the HMAC (under the auth key assigned to this client) of the rest of the URL, any POST data, and any other state that the server will taken into account.

As long as all requests are idempotent (e.g., for non-idempotent actions, you make sure to include a unique identifier somewhere in the URL parameters or in the POST data, and the server does replay detection), this should work OK to protect the authenticity and integrity of requests from the client to the server.

However, it has some security limitations.  It does not protect confidentiality.  It also does not protect other request headers, response data, and all sorts of other stuff.  For this reason, it is not as secure as just using SSL.  For instance, a site built using this approach likely will not be secure against man-in-the-middle attacks, due to the amount of other stuff that isn't protected by a HMAC, and thus won't be safe to use on an open Wifi network.  For this reason, I suggest you just use SSL across the board and simplify your life, rather than trying to invent your own cryptographic request authentication format.

Security against password guessing. You'll note that none of my proposed approaches involve generating the cryptographic key as a function of the user's password.  Users typically choose passwords.  You should expect this will be especially true on mobile platforms, where entering passwords is a pain. For that reason, cryptographic keys derived from passwords will generally provide weak security and can often be broken by dictionary search.  For instance, an eavesdropper who captures any one request will be able to mount a brute-force password search attack to recover the password and thus the crypto key, if the crypto key is derived from the password.

While PBKDF2 is an attempt to mitigate this as best as possible, the fundamental vulnerability remains.  For this reason, I believe it is better to avoid using cryptographic keys that are derived from passwords, whereever possible.  My solutions above are more robust in the face of weak user passwords, because they do not involve sending a password or anything derived as a function of the password in the clear over any connection.

The third-party design. You mention you hired a third party to come up with a design, and they proposed using something like MD5(secrets + data + more data).  This is a bad idea.  Don't do it.  It has multiple cryptographic flaws.  First, MD5(secret + data) is a poor message authentication code; it is susceptible to message extension attacks.  Second, combining different kinds of data by concatenation is a bad idea and one of the top-ten most common crypto mistakes; both Amazon and Flickr had high-profile security flaws due to this.  Instead, I recommend that you use a proper message authentication code (like HMAC), and that you use proper methods for concatenating the data fields that you want to authenticate, e.g., by including length fields.


How dangerous is reflected request query strings?

You can host all the phishing emails there. For example:

  We have detected suspicious behavior on your account. All furthur login requests will be denied. Please use the alternative login form at http://example.com/ to do a secure log in and unlock your account.


Does it matter that my browser shows an out-of-date certificate when a website uses service workers?

If the system's time and/or date of the device you are using to browse the website is miss-configured, you can see a valid certificate shown as invalid. This can happen in two possible scenarios:

The system's date is before the "Not valid before" value of the
public certificate.

The system's date is after the "Not valid after" value of the public
certificate.


Is pull inherently more secure than push?

I don't think there is a big difference between the two models. If you implement the "push" model, which I'll call the "notification" model, the user can still log into the site before getting the notification. If you implement the "pull" model, which I think of as the "polling" model, an attacker can still email the user with a forged notification, effectively converting your no-notification polling model into a notification model (the attacker would need to know that a notification is expected to achieve this effectively). So, either way, you are basically supporting both models.

In the end, your user must be sufficiently sophisticated to avoid clicking on bad links in their email, and generally avoiding going to incorrect websites. If they aren't, then they are open to phishing and other attacks. Implement 2FA, consider something like U2F, train your users about phishing attacks, and make sure that you're support team knows how to respond to problems.


Why are people saying that the X Window System is not secure?

This is a poorly phrased question.  For instance, it does not define what is meant by "secure".  That makes it harder to provide a useful answer.
Here are three possible security concerns, and how X11 fares:

Isolation between apps.  X11 does not isolate apps from each other.  If one app is malicious, it can log all keystrokes, tamper with other apps windows, steal the contents of copy/paste buffers, inject keystrokes into other windows, etc.  (Windows has similar security properties.)

Preventing privilege escalation. X11 apps run as a non-root user.  However, on most platforms the X11 drivers run as root, so they can access the display hardware.  This introduces the risk that a malicious app might be able to exploit some security vulnerability in the X11 code and use it to become root.  This is a serious risk, because X11 is a complex system with a tremendous amount of code, and all it takes is one security vulnerability anywhere in that code to make a privilege escalation attack possible.  This is indeed a concern.
The question refers to privilege separating the X11 code.  I do not know how easy or hard this is to do, or how effective OpenBSD's attempt is.  However, the aim of privilege separation is to reduce the likelihood of such privilege escalation vulnerabilities.

Enabling remote attacks. If I run X11 on my Linux machine, does that make it easy (or possible) for remote attackers to "hack" my machine?  The answer is no.  Remote attackers have no way to access or talk to X11, so running X11 on my machine does not make my machine insecure.

All in all, I would say that X11 does pose some security risks, but they are relatively minor, compared to the risks you are already accepting when you use any desktop OS.  In the desktop world, every app you run already must be completely trusted (since any one rogue app you run has access to all your files and everything, and can ruin your life); X11 does not make this fact any worse.
Therefore, I would not hesitate to use X11, at least not on security grounds.  If you find X11 useful, go ahead and use it.


If I am not mistaken, importing your own SSL certificates is just for the connections which you make to the device's own web interface so that won't help you to accomplish your goal.

What you would need to do is:

Create your own root CA
Make those devices trust your own root certificate
Redirect all SSL traffic from those devices to your proxy
When a device tries to connect to spy.samsung.com present an SSL certificate for spy.samsung.com signed with your own root certificate.
Forward requests to real spy.samsung.com and replies back to the device.

The hardest part is #2, which requires access to the device on a level which will allow you to modify its trusted certificate store.

The complexity of that task may range from trivial, such as logging in through SSH and appending your root certificate to curl-ca-bundle.crt or a similarily named file somewhere on the device, to the extremely difficult, such as having to defeat boot-loader lock and code-signing verification to patch an executable in the device's firmware so you can insert your root certificate or even having to find and extract its private key if the device is using mutual authentication with the server.

Depending on your place of residence some of those activites (such as reverse-engineering the device) might even be illegal, not to mention that if you already have to resort to reverse-engineering you might as well look at the code to see what is being sent/received.


How to securely store secrets in Docker container?

Docker Secrets is the new recommended method for sharing & storing secrets inside containers. Docker deliberately opted to store secrets in files under /run/secrets over the environment variable approach.


Can free Wi-Fi hotspot providers snoop on HTTPS communications?

Generally speaking†, one cannot intercept HTTPS communications.

However, a hot-spot provider can do the following:

See the hostnames you want to connect to from your DNS requests
See the IP addresses you connect to
If you type in say http://yourbank.com, hoping for a redirect to https://yourbank.com, the hot-spot owner can intercept that and redirect you or serve you their own content. This is one reason why HSTS exists. If the site uses HSTS or you type in https://yourbank.com or you use a VPN you are fine.

† With the following assumptions:

the site gets a reasonable score on https://www.ssllabs.com/ssltest/
the browser gets a reasonable score on https://www.ssllabs.com/ssltest/viewMyClient.html
the user doesn't override cert warnings


Free Alternatives in Web-Application Mapping Software

There's a number of program you can use for this.  First off I would mention that there's a free version of burp that does most (if not all) of what you're likely to need for running through the exercises in the book.

Good alternatives include

OWASP ZAP
Ironwasp
Conext CAT


How can I make a master policy file for Windows using Python?

My bad, that should have been "folder" not file.  There is info about the group policy folders located here.  Technet also has a lot of info about how to make local policies using gpedit.msc.

As far as having Python replace a directory, that's also available in Stack Overflow and in the Python documentation.  You'd need to run any script that does that as Administrator or System.


What is going on with my VPN and is it anything to worry about?

You are looking at the wrong address.  There, at the very top of the "UK address" picture, you see that it is in fact an address in Switzerland.  The IP address is what is traceable about your connection, and the address in that picture (185.236.201.147) is listed in Zurich.

In fact, you can also look at the GEOLOC value and see coordinates in Switzerland, as well as a COUNTRY value of CH.  So the IP address you are looking at is registered in Switzerland.

Below the information on the IP address, you are seeing information about the registered assignee who controls that IP address (the IP's owner).  The owner happens to have a business mailing address in the UK, which is what you're seeing in the second section there.  Let me be very clear, the second data set on that page is not information about the IP address, it is information about the registered owner of the IP; therefore it is not required to have any details at all matching the IP's actual/physical location  (In your 2nd picture, the registered owner of the IP address is the Zurich office for GlobalAXS, hence the CH mailing address.)

So, the TLDR answer here is that you really are using a VPN hosted in CH, and you're just looking at the wrong info on that web site.

The more fun answer is that the information you see listed for the IP doesn't even necessarily have to be accurate.  Last week I had an IP address listed as from Ecuador on a cloud-hosted machine that is sitting in a Microsoft data center in West Virginia, USA.  I've heard of other people with machines in the same data center that had IP addresses that were originally assigned to India.  While these IP assignment databases are supposed to be properly updated, a large enough company that has IP addresses in several different regions and private interconnects between those regions could actually cross-publish routes and get stuff really screwy.  Microsoft was apparently running out of USA based IP addresses so they funneled some of the Ecuadorian and Indian addresses into the East USA zone; whatever, the routes all still work in both directions (it still goes into a MS Azure center).  But that just goes to prove that geo-IP lookups can be very inaccurate.

And with a VPN the service you're paying for is to protect you and your identity.  Both of these (even if it had been in the UK) do that.  In both pictures the IP addresses shown are not yours and instead map back to a GlobalAXS Network Operations Centre.  That means the VPN is working an you're secure; anyone looking will see that the client they are talking to is GlobalAXS and not IkiH.


It's an interesting presentation, I had not seen this before.
My reading of this is:
step #1 is modify the display controller firmware. So yes, physical compromise of the device, but it could conceivably be done via classic imported malware.
Only after the display controller firmware is modified is there a capability to have the display altered under the direction of custom encoded pixels.
The modified controller could then be commanded to display Red as Green, or insert custom text to appear at designated screen coordinates.
He does rather cavalierly talk about distributing custom pixel code in pictures and videos, but he is overly casual in his speech. This is essentially a form of steganography. The existence of the steg content does nothing without external code running to extract and parse it. In short, the monitor has to already be compromised.
I don't believe there is any mechanism for the compromised display controllers to write back and compromise the main computer OS or memory but can not state that with complete confidence.
As far as dealing with a compromised display controller, yes re-flashing the firmware would eliminate the compromise. Can it be detected? I don't know if the display firmware is even readable. If it is, you'd still have to have a reference to detect it.
Bottom line is that the threat vector is firmware flashing, and even then it's limited to altering the display.


nmap+V and amap are old patches and forks of nmap that was used before nmap added version scanning into the core build. Both tools are mostly obsolete now. Even the AMAP website agrees.

nmap -sV -V -ip address-

The -V flag increases the verbosity of nmap's output, giving you the exact header information that nmap uses to determine what service/version is running on the port.

In the case of non-standard programs, your best bet would be to use Google to search for more information about a particular header or other information that nmap returns. There is really too many obscure programs for anyone to provide a comprehensive list in one place.


I think it's perfectly reasonable to be worried (I would be). Even if these machines have no vulnerable services now, your lab users are bound to install something dangerous sooner or later and chaos will ensue. For now, if nmap is overkill on your network, you can log onto each machine and run netstat to get a first glance at your attack surface.

You should definitely report this to your IT services and request some kind of NAT and / or firewalling.

If they do not want to act, though, keep in mind that you should refrain from remotely hacking that printer / vulnerable Mac to prove your point. Newspapers are filled with stories of sysadmins that got fired like that. Bite the bullet and keep a written track of your exchanges.


Should the RTP feed from a surveillance camera be protected?

Authentication/Login should always be done over HTTPS if its an viable option, consider just the amount of admins that uses the same passwords for different systems. There are so many reasons.

RTP is from 1989 originally, and to run anything over it today should almost be criminal. If it have any form of security perspective, a bad guy could DOS the camera feed or send a faked time-loop (like they do in the movies, yes we actually did that in our office for a demonstration).

I'd use one of those two, and make sure to enable both authentication and encryption (both optional).


How is it secure to open documents with embedded/linked fonts and images

Opening a document is only secure if all the components used to edit/display it contains no security flaws.

If a security flaw exists in the software used to display/edit the document or in any component (library or service) that it uses to process some elements like images or fonts, a specially crafted document can exploit the security flaw.

What it actually attacked here is not the document itself but one specific program or library that is used to process it. Said differently a rogue document could exploit the security flaw when edited with software A but not with software B.


Is it posible to validate a new user account/reset password without sending an email or phone number?

If the focus of the solution is on a mechanism to authenticate a user without collecting any of their personal info (like email id), then using a delegated authentication mechanism is one way to go. For example, OpenID could be used to leverage an external auth server for our authentication needs. This way, we don't have to store any personal information of the user. More information can be found here.

Now, if the focus is to implement an authentication mechanism yourself, and you do not want to use any recovery back-channel (such as email or phone number), then a multi-factor (MFA) option is the way to go - Google Authenticator, sending a push message to your phone app and so on. MFA for a desktop solution could be achieved via a 'soft token'. There are a few well known providers, such as Entrust or AuthAnvil.


Is this a security issue at the Remote Host or the Local Host?

127.0.0.1 is "localhost" and can be contacted only from the machine itself. So the connections you see in the logs must come from something on the machine 'A' itself.

PROPFIND is part of WebDAV, which can be viewed as an extension on HTTP to turn it into a file server. "Microsoft-WebDAV-MiniRedir" is a Windows component which allows folders exported with WebDAV to be accessible as UNC shares; in other words, if there is a Web server on localhost, which serves files through WebDAV, and some application wants to access these files with a path like "\\localhost\test2\desktop.ini", then the Web server will receive connections like the ones you see in your logs.

So my guess is that there is something related to the browser which tries to read a file called "\\localhost\test2\desktop.ini"; the WebDAV mini-redirector then tries to convert that into a HTTP PROPFIND request to the Web server on localhost. That Web server happens not to do WebDAV at all, resulting in an error response (405) and a log entry.

The good question, now, is: what is trying to read "\\localhost\test2\desktop.ini" ? A possible scenario is the following: the Web page served by machine 'B' contains a link, e.g. something like this:

<img src="\\localhost\test2\desktop.ini" />

and such a link could be the result of a configuration error on 'B', or maybe, possibly, some sort of automated attack attempt (the site on 'B' trying to gain some access to files on 'A'). I find the latter relatively implausible (it would be a relatively clumsy attempt) and, in any case, it did not work (your Apache server does not talk WebDAV). To make sure, search for such a link in the Web page source as served by 'B'.

Other scenarios to investigate include a proxy configuration on the browser, or some "security tool" which tries to scan files in search of virus, and may do so on remote files through WebDAV. In the jungle of Microsoft products, stranger things have appeared. Some Googling shows that other people have found such log entries, e.g. there and there.


Why is filling up at the gas pump require a quick scan of the Credit/Debit card?

The way the magnetic stripe reader works is by detecting changes in the magnetic field of the stripe as it passes under/across the head, similar to a magnetic tape head.  In fact, mag stripes were invented from magnetic tape.  Just like swiping your card at a point-of-sale kiosk, removing the card "quickly" is necessary to read the magnetic field flipping.  (There's a certain minimum rate for the flips to be properly detected, but it varies from reader design to reader design.)  Feel free to leave the card in there, but it just won't be read by the pump.


How to restrict file access on a local Windows Server?

I just started a new software development company...we have 10 employees.

This implies you have a significant investment of capital. Yet, reading between the lines, there is a huge amount of risk and in efficiency in your setup.

Your code assets should be managed in a version control system. Build and deployment should be scripted. Your development and production environments should reside on different hardware.

Yes, you should be managing much more than just code artefacts - but a file share is a really bad place to store such design documents, test plans and bug reports. If your staff can't signpost you to better, free alternatives, then you are employing the wrong people.

I'm not saying you shouldn't have a file server, but not for sharing most of the development team's product.

  I want to be able to protect the folders so that the staff working on the folder cannot copy files from the server.

This is simply not possible with the shared folder model. It is possible with a version control system but a very bad idea. Many people entering the business have an over-inflated opinion of the quality of their product and are convinced everyone is trying to steal it, including their own employees. You are unlikely to be in a position to be able to afford a truly effective IP management/DLP solution right now (and what you describe falls a very long way short). There are better ways to solve these problems.


What's the most secure way to send information from one device to another?

Depending on your available resources you could look into encrypted short burst radio transmissions.

http://en.wikipedia.org/wiki/Burst_transmission

That would definitely be the most secure one-way method.

With smaller means, just use regular internet connection and encrypt your file sharing. If the question were more specific, I could provide a more specific answer.

Web RTC possibilities seem interesting.

Or you could just encrypt the files and then send them with FTP, properly encrypted, it doesn't matter if someone intercepts them.


What is properly way to manage and remove symmetric key in C#

Yes, that's generally good enough.

If you are worried about residual current then you could first randomize it or use 0xFF and then 0x00 to fill the array. However, retrieving memory from the chips itself is not that easy.

Note that C# and other managed languages may shuffle / copy memory locations when memory management is performed (e.g. compacting the memory after garbage collection). The shorter the life time of the key the less chance it remains in memory somewhere.

Another issue is that the (just-in-time) compiler optimizes out the memory. The only thing against that is to actually use the memory:

byte total;
for (int i = 0; i < array.length; i++)
{
     total |= array[i];
}
if (total != 0)
{
    throw new Exception();
}

this makes it much harder and therefore less likely that the code will be optimized out.

And yes, doing secure coding in managed languages has a lot of advantages, but there are also disadvantages like the ones explained above.


There's a number of ways that you could achieve this

As @raz says in comments use Tor.  The Tor network is designed to anonymise Internet traffic so this would fit your bill quite well.  Using something like Tails OS could be an easy way to get started for you in that line.
As @zviad-gabroshvili says use a proxy.  there are a wide range of proxy services on the Internet.
There are various services that will contact a URL as part of their operation (e.g. search engines).  If you put a link on a page that gets indexed, it's likely that the web search crawler will, in effect, send a request to your target anonymously (well in a way that wouldn't tie back to you directly)


What other place (besides libc) attacker redirect control flow to after an attack such as buffer-overflow succeeded

Update: You seem to be expecting more concrete information, so I expanded my post a bit. As far as I know, however, no code besides the actual program, libraries and kernel code is usually mapped to memory when your program is run in user mode.

There are several places you could redirect the control flow to, in case the stack is not executable:

ret2data: Place the exploit code into the data section and then point the return address there. Often not possible.
ret2text: Jump to existing code in the .text section of the exploited binary. This includes jumping to DLLs and other shared libraries (and theoretically even kernel code, without a mode switch).
chained returns: A technique that can be used to combine several methods. Basically, you prepare the stack so that the returning instruction of the first function will jump to the second function, and so on.
partial returns: Another technique. You don't have to jump to the beginning of a function, but can also jump in the middle or near the end.
ret2syscall: A practical example what you can do. Basically, you have an int 0x80 instruction (a linux system call that expects its arguments in registers) and any function that cleans up the stack, for instance pop eax; pop ecx; pop edx; pop ebx; ret; You fill the stack with the address of the pop eax instruction, then the values of the registers and then the address of the syscall.


Web site accepting authentication via GET

Question 1: this is not considered secure for a number of reasons:

The password can be seen on the URL
The password can be seen on browser history
All the passwords will be on server logs
If the user logs on the site, and there's a link pointing to an external site, and the user clicks it, the password is leaked
Spyware with URL monitoring will be able to get the password

I think the problem #3 is the most troubling. If someone gains access to the webserver, he will have all the passwords for every logged user, in plain text. I would fire the person designing this login scheme.

Even if the site employs SSL, those attacks can be done and get the passwords.

Question 2: This is not an attack, is a design error. It opens way to some attacks. Search for CSRF (or XSRF) for the easiest way to attack this design error.

EDIT: The above is true IF the authentication form sends data via GET, and it isn't the case.

If the attacker can create a form convincing the user to supply his login and password, it does not matter how secure the server-side is. Does not matter if the form is using GET or POST, HTTPS or HTTP, Javascript or Flash or Java applet or virtual machine running Linux over asm.js.


(This is a very non-technical description of the whole process. Feel free to comment and ask)

The mechanism in practice is the same in all systems and it has much to do with why these things are called viruses instead of, say, bacteria.

A virus is not "alive" in that it lacks essential machinery. What it does is hijack the machinery of a more complex entity such as a cell, and make it do its bidding -- the virus may be no more than a hijacking mechanism with the "bidding" list as payload.

A computer virus is very similar to this simple structure.

How does the hijacking work?

A computer system has to have a boot sequence - first you do this, then you do that, further instructions are here, then... - and an action sequence (which is used to launch programs).

For example when you try to run an executable file, the system opens the file, finds out what it needs (and complains if it can't fulfill those needs - "missing library" for example), finds out how to place all the components packed in the .exe file in memory, determines where to do it, updates the components with information about each other so that they can communicate, unpacks the components and places them in the prepared places in memory, and finally releases a measure of control to the component marked "first".

The virus hijacks this process by (two examples):

locate the list of places where executable code is going to be activated
(MBR, boot sector, OS loader, OS stub, auto-executing scripts, boot processes, ...)
inject itself into this list, so that the system has one more thing to do when it starts, and that thing is breathing life into the virus chrysalis. This can be done by modifying the OS's list of things to do, or by placing itself in some convenient place such as the auto-run folder or Run registry branch in Windows. Anything placed there will be run at startup.
or it can replace one of the components, saving it somewhere else. When the system activates the component believing it to be legit, the virus does its thing, then it also retrieves the hibernated component and activates it as if it was the system. So in effect the sequence is again one step longer, but "officially", from outside, the number of steps is unchanged.

The virus may also write itself inside the diagnostic routines of the OS so that they report nothing out of the ordinary. This process may be run very close to the hardware, so that the infection is very difficult to detect.

To infect executables the virus does the same in a slightly different way. It can modify the internal "manifest" of the file so that the system will actually run the virus. The virus will then extract from its bloated "body" the carcass of the original process, and activate it in turn. The user will see the desired process running and not notice the slight delay in activation.

Disinfection requires knowledge of the virus so that the original file can be extracted from the infected object, and used to replace it altogether.

More sophisticated ways of hiding exist: many executable files have internal areas that are mostly zeroes, used as temporary storage of one kind or another. The virus hides there, and only does a slight modification to the file so that the "first component" to be activated isn't the original one but the empty area where the virus now resides. Being "inside" the file, the file size is now unchanged. The virus, upon receiving control, will move itself to some other place, again zeroing back the area (in memory) where it was hiding, and pass control to the old "first component", which will then notice nothing amiss.


Read-Only USB thumb as Linux boot encryption authentication

You can create a LUKS volume that relies on a keyfile, rather than on some user input.

There's a guide here, but I've not followed it myself.  It seems quite sound though, from a quick read through.

LUKS USB key unlock

Consider also the pros and cons of doing this.  A pro is that your key can be longer than you could comfortably remember, but a con is that it's physical, and easily stolen.  If you're looking for a higher level of security, I expect it's possible to require both a keyfile and passphrase (at the same time, that gives you more stuff to forget/lose).

Weigh up your options before doing something like this.


Any suggestions while testing a sandboxing driver?

There are two approaches, the quantitative and the qualitative.

The quantitative consists of fuzzing the input to the sandboxing driver. Use a fuzzing framework like Peach, Sulley or other to fuzz that input and look for crashes or file operations outside the sandbox.

The qualitative approach involves reverse engineering and understand the sandboxing mechanism. Then try to combine that understanding with different features Windows provides and different levels of privilege other components might have. The sandbox might restrict file and network operations but will it restrict injecting into a different process?

Scenario ideas:

Manipulating other processes and the system to write outside the sandbox
Using native system routines NtWriteFile and ZwWriteFile
Loading drivers and writing to devices like \\Device\Harddisk4\Partition2\mydir\myfile.txt, \DosDevices\c:\path_to_file.txt, \Device\Tcp
Loading DLLs with rundll32.exe
Unhooking or confusing hooking mechanisms
Using symbolic links to confuse the sandbox
Using alternate data streams fileinsandbox.txt:fileoutsidesandbox.txt
Performing directory traversals path\in\sandbox\..\..\..\outside.txt
Using environment variables like %SystemRoot%, %WinDir%, %TEMP%


Phishing: allow # in user provided redirect URL?

The # in a URI denotes a fragment identifier. This is not sent to the server, and therefore cannot be used to cause a redirect without client-side help.

It should be safe to send back to a user, I would be more concerned with the rest of the URL than with the fragment.


Is it possible to execute a php script in an image file?

Yes, your server could run PHP code within an image file if it is not configured correctly:

http://www.phpclasses.org/blog/post/67-PHP-security-exploit-with-GIF-images.html

An example from that is image.gif.php. A file can be be both a valid image and a valid PHP script, it's not sufficient to simply check image size or other properties. Nor is it sufficient to strip metadata, an uncompressed GIF can contain PHP as image data (though it may be unpretty), PNG supports arbitrary data chunks.

The flaw is accepting uploads with insufficient sanity checking, specifically attempting to prevent unwanted filenames (e.g .php) by using a non-anchored regex like \.(png|gif|jpg|jpeg) (no $ anchor), and allowing those images to be served from a directory with PHP processing enabled. Best practise is that you should probably never use a user provided filename as-is.

These are fairly classic data validation and input validation failures.

If you follow the PHP installation instructions (for Apache 2) you'll have something like this in your Apache config:

<FilesMatch "\.ph(p[2-6]?|tml)$">
    SetHandler application/x-httpd-php
</FilesMatch>

Note the $ anchor, it will prevent file.php.gif from being interpreted by PHP.
(What's missing from those instructions is making sure that PHP is limited by a <Directory> context containing only trusted code, and not writeable by the web server user.)

If you don't follow those instructions, and use mod_mime's AddType (or AddHandler) instead:

AddType application/x-httpd-php .php      # STOP!

This can cause the same problem because mod_mime may do something you don't expect with multiple extensions. See http://blog.dynom.nl/archives/Be-careful-with-double-extensions_20081024_25.html (thanks to Hendrik Brummermann for pointing this out). This risk can be mitigated with correctly configured <Directory> context to allow only trusted code.

This document (PDF) is a little old, but it covers the mitigations well:
http://www.net-security.org/dl/articles/php-file-upload.pdf

Another possible source of problems is insecure include/require statements (also covered in that PDF) which allow an attacker to include uploaded content by altering query strings or HTTP request headers.

See also the recent related question: Risks of a PHP image upload form
(though I do not think it is correct to rely on getimagesize to verify images), and
Use PHP to check uploaded image file for malware? (which contains a useful set of links).


Minimal working configuration for reasonable security in openssh on Linux

If you are running fairly recent version of openssh, I would recommend rather

PermitRootLogin without-password

It should not matter if you do not allow password authentication (but for further when you will decide to allow it for some reason).
Not sure what you mean by "to be able to root", but if you want to allow root login, you also need to list that user in AllowUsers option, if <zzz-my-user> is not root.
UsePrivilegeSeparation sandbox is current default. It works fine and adds another layer of security.

Further options depends on your use cases that you need to use and what you want to protect against. But generally forbidding Tunnel, Port forwarding or X11 forwarding might be way if you don't want to use it.


Is header('Location: ../page.php?param='.$param); vulnerable to unvalidated redirects?

I don't think there is a risk for an open redirect vulnerability, since anything after the ? will be interpreted as query parameters and not a part of the path. But you should change your code anyway, since you do not make sure that the param is actually URL-encoded. Do this with urlencode():

header('Location: ../page.php?param='.urlencode($param));

However, if you use a version of PHP older than 5.1.2 you are vulnerable to header injection (see documentation). By sending a param that includes a newline an attacker could set multiple headers (or just set the location header again, overwriting the old value). Using urlencode() fixes that since \n would be encoded as %0A.

The whole construct could be unnecessary though - perhaps you can just check both $_POST and $_GET for param in page.php?


Snort supports several output formats for the Log Parser where CSV format is mostly used. To configure Snort to use the CSV output format add the following line in the snort.conf file:

output alert_csv: alert.csv default

There are by default 28 fields available for log analysis that include timestamp, sig_generator, sig_id, sig_rev, msg, proto etc. For understanding Snort Log Management i recommend to read "Managing Snort Alerts"


Security implications for email address and url changes?

What program are you using to view the email?

It looks as if you are using the web interface from mail.com to read the email (mail.com is an email provider).

If this is the case, they are simply using an intermediate script as target of the addresses. When you click an address from the webmail, the goal is that the user writes a new email to that address, so it needs to be rewritten, instead of having the webmail opening a local MUA.

In the second case, where it is a http url, the name suggests that you are being redirected through https://3c-lxa.mail.com/mail/client/dereferrer?redirectUrl=… in order to conceal the url from which you were reading your email, as that might contain sensitive information, such as session tokens, your address, etc.


Does the length of Salt data influence how hard or easy it would be to crack/match a hashed password?

The length of the salt is not important once it has exceeded the minimum below which pre-calculation becomes cheap.

To quote Wikipedia:

  Early Unix implementations limited passwords to 8 characters and used
  a 12-bit salt, which allowed for 4,096 possible salt values. This was
  an appropriate balance for 1970s computational and storage costs.

By my math, a 12-bit salt means someone could pre-compute rainbow tables for all 4096 salts; assuming a 7-8 character password, all it takes is 16 petabytes...  certainly not out of the reach of many well-funded attackers today. Modern cryptographic algorithms tend toward 8- to 32-character salts in order to raise the bar (see table 2 here).

But I believe the length of the salt does not, for example, meaningfully impact the speed of each password calculation*.  The choice of a good password algorithm will slow computations and lower the speed at which an attacker can mount a brute force attack; whether that algorithm is getting +8 characters of input is not going to make a significant difference compared to +16 characters or +32.

So as long as the salt isn't so small as to make pre-computation feasible, it's doing half of it's job.  (The other half is to prevent Alice and Bob from having the same hash if they have the same password).

*That's my belief...  but I'm not a mathematician or a crypto coder.  Take that statement with a grain of, well, you know...


Why are web servers ubiquitously configured by blacklisting inaccessible files instead of whitelisting the accessible ones?

Because web-server content changes frequently and it would be annoying to have to constantly add new files to a whitelist.

  For ASP.NET, it's a bit more work, but if this were a goal, tools could be written to whitelist .aspx files during deployment, so that no other .aspx files could be executed, no matter where they are located.

But you don't typically deploy .aspx, .php files through a tool.  You just drop them in the directory.  It would require a huge change in how scripting languages work.  They would cease to be scripting languages and become more like compiled languages.

  Allowing everything and then trying to plug the holes is surely one of the "security 101" no-no's. Why is it so ubiquitous in web server set-ups then?

Going the other way around would be based on the assumption that allowing user uploads is a normal use-case for everyone installing the webserver. Its not very likely that the majority of webserver instances allow user uploads, as most are undoubtedly corporate intranets or non-interactive sites that simply publish material to the user.


ssh tunneling /port forwarding/access different subnet

You can use Meterpreter for pivoting. There's a good tutorial described in Metasploit Unleashed.

meterpreter > ipconfig

Citrix XenServer PV Ethernet Adapter #2 - Packet Scheduler Miniport
Hardware MAC: d2:d6:70:fa:de:65
IP Address  : 10.1.13.3
Netmask     : 255.255.255.0

MS TCP Loopback interface
Hardware MAC: 00:00:00:00:00:00
IP Address  : 127.0.0.1
Netmask     : 255.0.0.0

Citrix XenServer PV Ethernet Adapter - Packet Scheduler Miniport
Hardware MAC: c6:ce:4e:d9:c9:6e
IP Address  : 192.168.1.201
Netmask     : 255.255.255.0

meterpreter > run autoroute -h
[*] Usage:   run autoroute [-r] -s subnet -n netmask
[*] Examples:
[*]   run autoroute -s 10.1.1.0 -n 255.255.255.0  # Add a route to 10.10.10.1/255.255.255.0
[*]   run autoroute -s 10.10.10.1                 # Netmask defaults to 255.255.255.0
[*]   run autoroute -s 10.10.10.1/24              # CIDR notation is also okay
[*]   run autoroute -p                            # Print active routing table
[*]   run autoroute -d -s 10.10.10.1              # Deletes the 10.10.10.1/255.255.255.0 route
[*] Use the "route" and "ipconfig" Meterpreter commands to learn about available routes
meterpreter > run autoroute -s 10.1.13.0/24
[*] Adding a route to 10.1.13.0/255.255.255.0...
[+] Added route to 10.1.13.0/255.255.255.0 via 192.168.1.201
[*] Use the -p option to list all active routes
meterpreter > run autoroute -p

Active Routing Table
====================

   Subnet             Netmask            Gateway
   ------             -------            -------
   10.1.13.0          255.255.255.0      Session 1


How should I diagnose a macintosh laptop running OS X Lion 10.7.5 automatically booting at 12:00:09 sharp every night?

I saw the launch process followed by an mDnsResponder process, followed by a process trying to connect to the wifi network, followed by iCal, MobileMe, processes trying to perform a synchronization.

There you have it. The machine was probably calling home to update the various applications whose data reside in Apple's cloud somewhere. I really doubt it's anything malicious.

If you are really worried, start up wireshark and monitor the network traffic during that time.


Your assumption is incorrect. Without Access-Control-Allow-Origin, all the other CORS response headers have zero effect at all.
Your thought is... misleading but not incorrect. You can always submit (simple) requests cross-origin, with credentials, utterly regardless of any CORS headers (including Access-Control-Allow-Credentials). The browser won't even know whether your server will return ACAC (or any other response header) until after the request is sent, because requests are sent before responses are returned.
You are possibly confused by the existence of CORS pre-flight requests, which are sent by the browser before sending the actual request. However, pre-flights are only used for non-simple requests. Broadly speaking, a non-simple request is just any request that can't be sent by an HTML form element. Adding credentials does NOT make a request non-simple; cookies and HTTP Basic/Digest Authorization headers are automatically included with cross-origin form submissions (in fact, there's no way for the client to prevent this), assuming the cookies aren't SameSite (and the browser isn't configured to block third-party cookies). In any case, though, a pre-flight response that contained ACAC: True but no ACAO (or ACAO with a mismatched origin, or ACAO: * and the request was to have included credentials) will result in the actual request just not being sent.


Your question is subject to some subtleties. Fasten your seat belt, I am going to be verbose.

Digital Medium

You want a "digital" medium. What is that exactly ? In a hard disk, a bit is written by changing the orientation of some magnetic dipoles, created by the "movement" (inasmuch as it can be defined as per quantum mechanics) of electrons in some of the atoms of the disk platter. Roughly speaking, each atom has a natural orientation, and the bit is stored by changing this orientation, i.e. "rotating" the atom. So there is some amount of "physical movement" in it. That's also true with flash memory: data is stored by accumulating "charges" in a semiconductor substrate; the charge corresponds to the "physical" movement of electrons (they hop between "bands" -- the kind-of orbital trajectories of electrons around atom kernels).

Now consider a sheet of some material in which you engrave some data; there again, that's just "moving around" some of the atoms of the material, so it is not qualitatively distinct from magnetic storage. You can make a distinction based on the amount of matter which is moved for a single bit, but this involves an arbitrary threshold.

Engraving has a remarkable record of long-term reliability for information storage. Consider this marvelous extract from the Schøyen collection:

This specific data file has been stored for more than 4500 years, in an area which has been scourged by countless wars in between. Empires have waxed and waned, and the soil soaked by the blood of warriors. Yet the information remained and was not lost; and, even better, it was stored at no marginal cost at all. As can be seen on the picture above, the medium would be good for a few more millenia at least. Data integrity is more threatened by, let's say, "encoding problems" (although that specific example could be translated nonetheless).

From the wording of your question, I assume that you would declare such engraving as "not digital" and reject it. Now, have a look at this:

This is a close-up view of the surface of a Compact Disc, of the "pressed" variety (i.e. not a CD-R). The bits are encoding by embossing, the dual operation of engraving; a big press is involved in the process. A CD-R does not use embossing; rather, the optical properties of a dye layer are modified with a laser, so a CD-R is more similar to printing on paper (in particular thermal printers as are common in payment terminals).

A CD is definitely "digital". However, it is not qualitatively distinct from the work of a Sumerian scribe on a stone slab. To declare the latter "not digital", you have to enforce a totally arbitrary threshold, which, as such, can be challenged.

You might want to make a distinction based on how the data can be read back into a computer, on the basis that a CD goes into a reader which outputs zeroes and ones on a wire. However, the slab picture above which you saw went to your computer over wires as zeroes and ones, so, there again, the distinction is subject to an arbitrary threshold. As a more striking example, consider QR codes like this one:

Now, a QR code printed on a sheet of paper, or engraved on a marble slab (to be read with tangential lighting, so as to shadow the pits), is that digital or not ?

Magnetism and EMP

Magnetism is a property of some materials. Magnetism is convenient for computerized data storage, because of the achievable high density, low latency, and possibility of multiple rewrites. However, this last property is also the bane of long-term storage: stored data can be affected by external magnetic sources, and is subject to gradual leakage. Even reading implies "grabbing" a bit of energy from the medium, thus weakening the data storage. Magneto-optical drives fare a bit better:

The medium magnetism can be altered only at high temperatures; at room temperature, it is "fixed".
Reading can be done optically (because the medium optical qualities are modified by the magnetic orientation which was forced upon it when it was last heated), thus leaving the magnetic field "alone".

Although manufacturers of magneto-optical drives claim reliable storage for long durations (decades, up to a century or two), this heavily depends on environmental conditions, and has never been tested "in full size" since the technology itself is not that old.

In particular, magnetic storage, whether magneto-optical or not, can be disrupted by applying a huge amount of magnetism in one go, something known as an Electromagnetic Pulse. This is the electromagnetic equivalent of a full stadium of beer-powered sport fans bellowing simultaneously (this has been used by some movie directors to obtain sound effects which are hard to simulate in a lab, resulting for instance in this scene -- a cricket stadium was involved). The method of choice for generating big EMP is through nuclear weapons: nuclear fission and fusion emit huge amounts of high energy gamma rays, which, by colliding with electrons, create the EMP. EMP can also be generated with non-nuclear devices, albeit with a much lower energy.

Hollywood, in its everlasting educational mission, has depicted a non-nuclear EMP in which the generating device looks like a jukebox. There has been some allowance for artistic license, though: a non-nuclear EMP works by rapid compression of a conductor in a magnetic field, where "rapid" means "high explosives". While the EMP effect has some military applications in specific situations (especially disabling onboard electronics in missiles, without needing to actually hit the missile with another missile), the common wisdom is that the explosives are more a general threat than the EMP itself. Would-be terrorists would not care about electromagnetism; they would just blow up things with the explosives alone.

A Faraday cage is effective against EMP proper; however, it does not block gamma rays and neutrons from a nuclear explosion, so gamma rays may enter the cage and generate a local pulse by interacting with the magnetic storage medium itself. The best protection for magnetic storage devices against a nuclear event is a deep underground bunker (it is also efficient for protecting human operators). That's what they do for NORAD: the headquarters are buried under a mountain.

Security: Threats and Goals

There are two sides to data security:

Protection against destruction: we want to be able to read the data back later on, possibly after many decades. An attacker may want to prevent us from doing that.
Protection against data theft: we do not want an attacker to be able to access the data.

These two goals are partially opposite to each other. The best protection against destruction is duplication; if you have a dozen copies of the data scattered over five continents, then the attacker will have a hard time obliterating them all (even Harry Potter could not do it in less than seven books). However, the more physical copies there are, the harder it is to protect them all against illicit copying. To some extent, theft is just another copy, so theft protects against destruction...

The situation is substantially different, depending on when and how you want to be able to access the stored data (data storage makes sense only if you plan to access the data at some point, even conditionally). If you just want long-term storage as a backup in case of a large-scale disaster, then you can use a non-networked storage facility, thereby removing all threats related to "hacking". Thus, protection against theft becomes a matter of physical security: store the data in a bunker, enlist guardians with (as @Lucas suggests) fierce dogs.

Guardians and dogs are a worry, though, because:

There are costs: you must feed them, entertain them, see to their general well-being and health, but in the same time subject them to enough stress and well-dosed misery so that they remain sharp and mean killing machines. And you must do that for the dogs, too.
Bribery is a problem. Each biological entity you allow around the premises is yet another target for subversion. Elaborate cross-spying schemes, with rewards on ratting out, can mitigate the issue, but involve even higher costs, and are considered to be "toxic to the workplace".

The storage medium can trigger the same kind of issue. If you use magnetic storage such as hard disks, then you must regularly (say, on a yearly basis) power the drives, and replace the units which fail to go live (invariably, some will fail to power up). This entails some redundancy (error correcting codes and variants, such as what is used in some RAID arrays) and, you get it, operators. Those pesky humans tend to have external lives, through which they can be controlled by adverse parties (give a man one million dollar, or kidnap his mother, and see if he keeps on refusing something as simple as pinching a hard disk).

If the facility does not need regular intervention, then you can, to some extent, use discretion as a substitute. For instance, consider the external lookout of the tomb of Tutankhamun (actually, a view from the Valley of the Kings, in Egypt, at a place where archeologists of the last two centuries have not yet defaced the landscape with their excavations):

and compare that to the tomb of Khufu, of, let's say, questionable inconspicuousness:

Now guess which one was not robbed in more than three thousand years ?

That's "Security through Obscurity" and it is known to be unreliable (e.g. see the plot of For a Few Dollars More), but "unreliable" does not mean that it never works...

Encryption

It is time to flourish our secret weapon: encryption. Encryption does not create secrecy; however, it concentrates secrecy. You have a key; it is a sequence of bits which have been generated with as much randomness as is practical (e.g. with coin flips, or sufficiently unbiased dice). Using the key, you can transform the data, even huge amounts of data, into a big heap of meaningless junk of roughly the same size of the original data; but, knowing the key, you can reverse the operation and recover your precious data.

A cryptographic key for symmetric encryption ("symmetric" means that the same key is used for encrypting and for decrypting) needs not be long; it just has to be long enough to thwart exhaustive search (i.e. it would be way too expensive, or even downright impossible with energetic resources available on Earth, to try out any substantial part of the set of possible key values). 128 bits are enough, but, in order to accommodate inflexible administrative regulations and quiet the qualms of managers who read too many science-fiction books, you might want to pump the key size up to 256 bits
(don't believe Dan Brown: exhaustive search is not a ultimately workable attack strategy, even if the attack machine is expensive; the scientific basis for this novel is no better than the quality of writing or the plausibility of the characters). As for the encryption algorithm, there is no guarantee that any specific algorithm will keep up its security promises for the next century, but there are good looking candidates which have sustained cryptanalytic advances for more than a decade, and that's not for lack of trying. I am of course speaking about the AES, which seems to be quite secure, and, furthermore, is Approved by governmental bodies throughout the World. AES might not ultimately protect your data, but it is the best that can be offered right now, and its security is plausible enough that you can get insurance against possible attacks at reasonable costs.

The secrecy concentration works like this: if the data you store is encrypted, then you no longer have to worry about theft of the data itself. You can store your gigabytes on any number of hard disks, copied and stored over dozens of remote places so that local disasters and "Acts of God" do not destroy it. Hundreds of underpaid henchmen may oversee the regular maintenance operations, with no bribery issue. You still need to take steps to guarantee the secrecy of the key, but the key is very small, so that's much easier.

The Solution

For long-term storage, I thus recommend the following scheme:

Encrypt the data, with AES and a 128-bit key (or 256-bit key if you need to woo investors).
Store the encrypted data on hard disks or pressed CD (the former have more capacity, the latter require much less maintenance), and put these in guarded bunkers in geographical locations which are far away from each other (preferably, in distinct countries over several continents).
Make a few copies of the key by engraving it on stone slabs (marble is classical; avoid limestone, which might lack durability in humid conditions; the Distinguished Customer will want to engrave on diamonds). Put the slabs in the safes of a few banks (do not conceal them in jewelry worn by your mistress -- that's the way of James Bond villains and it does not work well, for long-term secrecy).

For extra security, split the key into parts with Shamir's Secret Sharing, so that plundering one bank does not endanger the secrecy of the key.

The trick, of course, is to make attacks more expensive than what the data is worth. If destroying or stealing your data involves a wide-scale nuclear war or a worldwide meteorite strike, then chances are that your data will be quite irrelevant in such conditions, and nobody will bother resorting to such drastic measures just to get at it.


SSH Tunnelling: How can I stop users being able to access services bound to localhost via port forwarding?

Port forwarding by the SSH daemon is done by a non-privileged child process of the ssh daemon.

ssh jeff@localhost -R 9999:localhost:22
sudo lsof -i
sshd      4856  jeff   10u  IPv4  21933      0t0  TCP localhost:9999 (LISTEN)

Thus we can see that the SSH process responsible for forwarding ports is owned by the user. There are fancy ways to go about tagging packets for custom handling, but I think the easiest is this:

iptables -A OUTPUT -m owner --gid-owner 1000 -d 127.0.0.0/8 -j REJECT --reject-with icmp-admin-prohibited

Put all your users into the same group, put that group in the rule, and put that rule at the top of your list before any allow rules. Note that I used 127.0.0.0/8 -- anything in the 127 netblock will get you to the local host, so don't just block 127.0.0.1.

Also, consider adding a similar rule to block access to your external interface IP. It is a crafty way to bypass the firewall rules.


USB 3.0 write protection switch question

Assuming you really mean a USB flash drive, well, it's up to the firmware running on the device itself to actually implement that functionality. And since these sticks are definitely at the very least end of profit margin, I wouldn't be surprised at all if there's plenty devices that have some slider that doesn't do anything.

If you're actually referring to an SD Card (or similar) in a USB 3.0 flash card reader: That small tab on the side doesn't actually do anything, but drivers are asked to please kindly pay some respect to the fact that the user shifted that plastic thing by 2mm and kindly refrain from writing to the card. So, no wonder your PC ignores it: many modern readers don't even come with sensor for the position of that tab anymore.

What's the information security content of this answer? Simple: Especially in the world of least-cost consumer electronics (but sadly, also in the world of server/datacenter hardware), it's often not a good idea to trust protection mechanisms that aren't enforced by yourself, but by some black box that the supplier hands you.

The "Windows bitlocker depended on hard drive hardware encryption if available; hard-drives signalled ability to encrypt, but then, really, didn't encrypt" is an example of that. The occassional "oh, there's a clearly intentional backdoor in this (insert market leader here)'s {VPN/firewall/email scanner/IDS}" is another example.


Is there anything standing in the way of email encryption going mainstream?

Software companies and email providers

Default support for PGP from Microsoft (Outlook.com and the Outlook mail client), Apple (default support in iOS and OSX), Yahoo and Gmail. They should make people aware, and create pgp-wizards to set it up with a few steps.

Google can make this happen, but they have a conflict of interest, bigger than Apple or MS. Maybe they can come up with a solution that keeps their business going and our mail safe.

A possible problem: the war on terror and those "thug states". Companies from the US are not allowed to export certain technologies to those countries. But I don't think this is the real problem, as these technologies are freely available worldwide.

Facebook and Twitter are not big parties in this, but they could start awareness campaigns, as privacy is something they like to promote.

Countries

I think it should be promoted by countries. The only big enough "country" that I can see this doing in the near future is the EU, although Germany could be a good start. But that will take more time.

What we can do

Install PGP ourselves and start to use it. I use it sometimes to mail stuff to myself from or to work, if only to get used to it.

Create manuals and installation methods and show how it can be used to work without hassle. So for mom and dad it should work by default when they send an email those people that use it (which probably means those addresses should be marked as having PGP), like you and me. It should even work for them without having to enter a password. That would mean the mail can be opened by anyone on that computer. On OSX you need to login to unlock the key, and I don't know how this works on Windows, but I hope it's similar.


You have to define what you are trying to protect and against whom. There are several assets:

Your geographical position
Who you call and who calls you
The contents of your conversations and SMS
Your phone bill

Then things are quite different, depending on whether the phone operator is a cooperative friend, a not-too-competent neutral third party, or an active attacker.

The phone bill is the simplest. If the operator is an attacker, then you are doomed. The theoretical countermeasure would be a tamper-resistant phone which records usage in a way which could convince a judge; I do not know of anything like that, although most phones keep a log of the most recent calls. If the operator is not an attacker, you have to trust the operator for not being hacked, and you also need to avoid your phone getting hacked, too. Smartphones, being full-fledge complex computers in their own right, with one or several network links active at all times (think about Bluetooth...), are susceptible to external hacking. So a non-smartphone may be advisable.

Anonymity concerns (geographical position, who you call and who calls you) are a hard problem. I heard that in some places, police services use cell phones to keep track of protesters in manifestations: a fake base station is setup, and broadcasts a big fat message of "I am the most powerful base station here, all phones in vicinity are to report immediately", and all the phones gladly answer "I am here !". If that situation is a concern for you, then you will need to "rotate" through numerous, short-lived receptors and accounts (obtained with fake names, of course), so this is expensive; and you will not receive calls, unless you use some VoIP software inside a VPN (so the operator sees that you connect to the VPN, but not what exits at the other side of that VPN).

A famous example of an anonymity concern, involving a satellite phone, occurred in 1996 with somewhat drastic consequences.

For the conversation contents, this is a question of encryption. In GSM phones, an algorithm called "A5" is used, with several variants: A5/0, A5/1, A5/2 and A5/3. A5/0 is "no encryption at all". A5/2 is "weak encryption", meant for export to countries of questionable reputation. A5/1 is a stream cipher which uses a 64-bit key but is actually weaker than that, with protection around 242.7 (the number may vary depending on how you count and some operational conditions such as the size of known cleartext; see this article for some details); that's much too low for comfort, so it should be assumed that the contents of A5/1-protected data can be learned by determined attackers (the Wikipedia page on A5/1 also cites some cracking efforts based on rainbow tables). A5/3 is also known as KASUMI and comes from the UMTS and GPRS worlds; it has some weaknesses but nothing fatal so far.

In any way, A5 encryption is only from the mobile phone to the nearest base station, so if the operator is an attacker (e.g. you are trying to evade legitimate eavesdropping by law enforcement agencies with which operators cooperate), then A5/x will not help you, regardless of what 'x' is. To survive that kind of attack, you need end-to-end encryption, which in turn requires a change of protocol, hence VoIP with custom encryption. An existing product is Zfone, from Phil Zimmermann (of PGP fame).

The biggest security conundrum here is that the standard protocols being quite bad at ensuring your security, you need a smartphone with custom software to obtain a reasonable level of protection; but security of the phone itself is also of paramount importance, and is much easier to achieve with a dumbphone.


What considerations are there for using USB WiFI adapters and how to protect against them?

The passwords/phrases for a WiFi connection are not stored on the adapter so there is little additional data risk. The dongle by itself is not sufficient to connect to a network. In other words, if you are worried about theft of the dongle leading to network access - it's not a big deal. (Of course, bigger threat of theft of device may be an issue but exists in both cases)

I postulate that the device might be able to be switched out with a specially crafted special one which includes unwanted additional functionality (remotely controllable keyboard?) but that would be beyond the scope of most attackers, and could hide easily in ANY attached USB device.


How is it possible for scammers on YouTube to use the same exact username as the author of the video?

The YouTube channel name is not a username, but a display name. They are not unique, so one does not have to perform any tricks to get a matching display name. For normal users without a brand account the display name is linked with the Google Account.
Those verification badges are not about protecting channel names, but an extra feature for channels with more than 100,000 subscribers.


Safe implementation of sharing encryption secrets (username, password) in the cloud

Encrypting the data with the public key of each agent is a way to implicitly authenticate the agent. You do not really know (in a setup where communications go through a potentially malicious cloud) if the agent really received the data, but you know that only the proper agent could decrypt it; hence, if the data has gone somewhere at all, then it went to the right agent. This looks like the good tool for your problem.

Note that public key encryption could be overkill. If you can arrange for the receiving agent and the data sender to share a common secret key (just a bunch of a few dozen random bytes), then you could use symmetric encryption to encrypt the data.

There are a few gotchas:

If you use a public key encryption scheme, then the sender must know the public keys of the agents beforehand, and in a reliable way. Depending on how you create and deploy the agents, this may or may not be easy.
The power of an agent to receive the data comes from its knowledge of his private key (or of the common shared secret key in the symmetric encryption case). You must take care of the storage of that private key, because acquiring a copy of the key would allow an attacker to decrypt your encrypted data.
Asymmetric encryption works only for limited messages. E.g., with 1024-bit RSA and the usual PKCS#1 padding, there is a hard limit at 117 bytes in a message. Also, RSA encryption and decryption is not too fast (although fast enough for most purposes). Hence, it is customary to use an hybrid scheme, in which you do not encrypt the message itself, but a random secret key (a bunch of random bytes) which you then use to encrypt the data itself, with a symmetric encryption system (AES), which is fast and unlimited in message length.
When there are malicious passive attackers, there often are active attackers as well. Passive attackers just spy on data; active attackers can also modify it. There are many smart attacks which can be made by subtly modifying encrypted data and observing the results (passwords sent in a SSL connection have been recovered that way). So you do not need only encryption, you also need integrity checks. One possibility is that the sender signs the encrypted packets, and the agents verify the signature before trying to decrypt them.

Myriads of deployed systems have stumbled on these, and they cannot be efficiently tested beforehand. You really should use an existing standard format for all that, with a support library which has already gone through the effort of implementing it properly. I suggest using CMS or OpenPGP. I do not know if C# already support those (I doubt it, especially in the case of OpenPGP), but Bouncy Castle is an open source library which does (it has a C# version).

As a final note, if you have many agents which should receive the same data, it may be more network-efficient to encrypt the data once with a secret key, which you then encrypt with the public key of each agent. This is called broadcast encryption and this is what pay TV vendors do (they send the very same voluminous content to millions of customers, which makes the broadcast thing not only worthwhile, but also downright necessary).


Can there still be SQL injection when storing the password as a hash?

Is this SQL injection?

Yes.

Why?

Let's look at what's happening here.

$query = "SELECT pass FROM social WHERE   email = '$id'";

This passes $id directly to the query. If $id is not sanitized, SQL injection will occur.

if($_POST && isset($_POST['submit'], $_POST['password'], $_POST['id'])) {
     $pass = ($_POST["password"]);
  $id =($_POST["id"]);
  echo $pass;

So we see here that $id is not sanitized when it is assigned the value of the user-supplied email address. When this $id is passed in to the query, the attacker can inject on the query.

Are there any other vulnerabilities?

Actually, the concern isn't bcrypt, but how users create passwords and interact with bcrypt. Ensure that you limit the size of passwords to 4096. Additional details here.

Secondly, currently, users can execute XSS:

echo $pass;

While this is intended for debugging purposes, take care to not leave debugging statements when you are ready to deploy your code.

Okay, but how do I fix this?

Parameterized queries.

If this is a brand new project, I would recommend using an ORM like Doctrine. It will automatically do parameterized queries for you. If that doesn't work for your needs, at minimum use PDO, which supports parameterized queries instead of mysqli which does not. You can read more here.

For more general information, OWASP is a good place to go for web application vulnerabilities: SQL Injection Prevention Cheat Sheet.


Altering a $_SESSION variable in PHP via XSS?

The answer to this depends on whether or not your application uses GET or POST data to populate SESSION data.

Say for example that the $_SESSION['username'] is populated when the user logins like this:

$_SESSION['username'] = $_GET['login-username']

As the XSS owns your client he can also modify the content of login-username variable, and thus control the session variables.

However it is important to know that the $_SESSION global variable array can only be modified server side.


CORS & CSRF Prevention for an REST based API

The Same Origin Policy would normally prevent your scenario from taking place:

GET http://api.example.com/me/token/generate
// parse the response

The response cannot be parsed through a third party domain making requests to your domain. The browser will normally block it due to the SOP.

I say normally because you have also added the following response header to relax the Same Origin rules:

header("Access-Control-Allow-Origin: " . $_SERVER["HTTP_ORIGIN"]);

Under the following misconception:

  The reason I "need" that is that, I'm not only using the REST API on
  the domain itself through forms and JavaScript. But I'm doing requests
  using cURL in C++.

This header does not have any bearing on cURL. The header is parsed by browsers only, implementing the SOP. It does nothing to prevent direct requests coming for a web client.

Solution

On your api.example.com domain, only allow the front-end to make requests through it using the user's browser:

Access-Control-Allow-Origin: example.com

On your example.com site, send the following header with all API AJAX requests:

X-Requested-With: XMLHttpRequest

See this answer for info on this. In a nutshell, this header cannot be sent cross domain without CORS being enabled.

Verify on your API backend that this header is present when a request is received. If it is not then it is an CSRF attack.

On your server-side requests using cURL, simply add the header manually. e.g.

X-Requested-With: cURL

As you're verifying that it is present, these requests will succeed.

Finally, add some authentication using cookies. Your logged in website users should have an authentication ticket that can be sent in a cookie, and you should have one for your backend cURL requests to use. This will ensure that nobody can use your API without permission. You may want to restrict the actions that web users can make using authorisation levels because otherwise they may try to maliciously execute a function that only your cURL server tool should do.


Would this authentication method prevent MiTMs getting the password?

The answer is no.

  The server replies with a unique identifier for the login

This step in itself contains a flaw. A MITM can simply intercept this response, change the unique identifier and observe how the client sends the encrypted identifier + the username. If the attacker has pre-computed rainbow tables for whichever unique identifier is injected, then gaining the password is trivial.


What is the format of SSL certificate that begins with BEGIN PKCS7?

Your certificate authority should not be giving you your private key. You should have generated it before making a CSR and including the public key (corresponding to the private one) in the CSR. The CA then signed the public key, without ever knowing your private key. Therefore, the private key should be in your PC and the CA can not give it to you. It should not have it.

What they should give you is a certificate, that confirms the public key (and by extension the private key) really belong to you and are not some random keys generated by an attacker.


Achieve total anonymity on public wifi using Android

First, with your phone manufacturers OS you can never be sure what is running and which applications send data where.

So as a first step you have to install a operating system where you can know what is inside. The best choice would be Replicant because it is 100% free software and you can get the source code for all parts of it.

Because Replicant supports a very limited number of devices, you might have to resort to LineageOS. Some parts of it are non-free, so you can never be 100% sure what it does, but still a lot better than your stock OS. Under no circumstances install the Google Apps package!

Then you switch the phone to flight mode and disable GPS and WiFi location services. Then you switch your MAC address and then enable only WiFi.

You can then surf the internet with Orbot and Orfox somewhat safe.

This will prevent websites from knowing where you are. Of course you still have to be very careful to not enter any personal details in any form on a website. Also, of course, you can only use Orfox to browse the web, never download any other apps and run them.


Once VPN is unplugged can work still monitor?

If you give them the username and password of your personal home router then they could (depending on model and firmware) configure it to log your traffic and forward the logs to them, or do other unethical things as described in this question. It's very unlikely that they would use the credentials to do such things, however I would refuse to give them control of my personal router, and instead get the configuration requirements and do it yourself.

Presuming that you keep control of your own equipment then once you disconnect or power down the work VPN device then they cannot use it to spy on what you do.


How would you detect whether customer data has been leaked?

Monitoring for records from the DB to be posted are really all you can do without direct access to the server.  You could try penetration testing the site yourself to look for holes, but that is probably unwise and possibly illegal depending on jurisdiction and the Terms of Use of the site and any contractual obligations you might have from when you wrote it.

If you are really concerned, you could simply ask permission to do periodic penetration testing on the sites of former clients to help ensure their sites remain secure.  If you find a vulnerability being exposed on one of them, you could then report it to them so they could either fix it or have you come in to fix it.


What rules should be enforced for users to create a strong password?

See this.

Important points:

You cannot test for password strength, on looking at the password alone. Password strength is a property of how the password is generated, which you cannot measure or even estimate more or less approximately by just looking at the password ("password meters" are a joke -- one of the best jokes: the kind which many people believe).
If you enforce strict rules on passwords, users will rebel and indulge in practices which degrade security (e.g. writing down the password on a stick-up note concealed under the keyboard, or reuse of passwords between sites).
You can help users by giving them a password generator which follows high entropy rules (this time you know how passwords are generated, so you can measure the entropy). The "correct horse" method would be a good idea.


Docker is never targeted security and privilege separation. The targeted goal of Docker is to be able to quickly install and deploy containers for anything, on anything.

For this reason, it is a common practice to put anything into docker containers, including security tools, but it is not hardened against breaking out from a container into the physical machine (although doing this is harder as it seems).

It is not a common practice that you download a docker container, write a 10 line long script on it and it will work like charm. Yes, this is what docker offers, but it doesn't fulfill it. Its main reason is the security - not being really security-hardened, they need to disable a lot of important linux kernel features (for example, they've simply disabled the unix datagram sockets, this is why syslogd doesn't work very well in docker containers).

If osquery works on an least two different distro families (deb- and rpm based ones), then yes, it should work also on Alpine. But it is your task to make it work.

So sure, you can make osquery work, but it won't be easy. You will have to dig deeply both into osquery, alpine, and docker. As a result, you will be able to build an osquery docker container, what you will be able to use as a base for your further developments.


Potentially dangerous request loads the page

Let's analyze what is happening here by looking at ASP.NET WebForms code.

First example, w/o =1

  [HttpRequestValidationException (0x80004005): A potentially dangerous Request.QueryString value was detected from the client (="alert(1)c__DisplayClass280_0.b__0(String key, String value) +22
     System.Web.HttpValueCollection.EnsureKeyValidated(String key) +9904693
     System.Web.HttpValueCollection.GetValues(String name) +17
     System.Web.UI.Page.DeterminePostBackMode() +99

If we run the code we can see that the exception originates in EnsureKeyValidated but we can get there from GetValues, from DeterminePostBackMode. So if you check there we see this:

      string[] values = nameValueCollection.GetValues((string) null);

so it's look like what we get here is retrieving all the values that are key-less. So the above query could be rewritten to the form null=<script>alert(313)</script>&. So the script is passed to be the value for an null/empty key.

Second example, w/ =1

In here you're making the key to be equal to the script, and the value for that key to be 1. The key's are encoded before they are passed to the server so this would not be an issue.

If you want to replicate the error, you could pass a=<script>alert(313)</script> and you would get the same error just originating from a different place:

  [HttpRequestValidationException (0x80004005): A potentially dangerous Request.QueryString value was detected from the client (a="alert(1)c__DisplayClass280_0.b__0(String key, String value) +22
     System.Web.HttpValueCollection.EnsureKeyValidated(String key) +9904693
     System.Web.HttpValueCollection.GetValues(Int32 index) +29
     System.Web.HttpValueCollection.ToString(Boolean urlencoded, IDictionary excludeKeys) +206
     System.Web.UI.Page.get_ClientQueryString() +411

If you need to you can control what is being denied.


Can a site vulnerable to XSS be used to attack a site with a CSRF vulnerability?

Yes. But first, lets understand what each of these attacks are:

XSS: An attack on the user; specifically through the browser and client-side.
CSRF: An attack on the server; often used to imposter a user; specifically through lack of a CSRF token during "privileged" requests.

With that being said:

The type of XSS attack is reflected or stored (this depends on how you want to execute the attack).
To pull off the CSRF attack, the site must have a predictable form privilege action (ie, no CSRF tokens). For example, if it's a bank when you transfer funds or updating email, etc.

If you were using stored XSS to CSRF you'd store the payload on the site, and then when the user loads the page with your stored XSS, you'd execute your vulnerable CSRF payload.

If you were using reflected XSS to CSRF, you'd be looking to phish users into execution of your malicious code (via XSS); a link would be sent to the victim, and upon clicking the link, your reflected XSS payload would execute the CSRF payload.

Why wouldn't this be a good attack, you get to:

Phish users.
Potentially harvest privileged information from a victim.


Can running a browser in Windows Compatibility Mode be a security issue?

There are a few things that are enabled when setting compatibility mode, such as shimming.

There are also other changes that may impact on security:-

  There have also been some other changes from Windows version to Windows version. In older versions for example, if a programm [sic] loaded a DLL, the search path for the DLL also included the current directory. This is a security issue, so newer versions of Windows by default don't search in the current directory. With the proper shim you can simulate the old behaviour.

This would normally only be a security issue for the local machine if an unprivileged user had permission to copy a malicious DLL to the Chrome installation folder it could be loaded in place of the normally loaded DLL and be executed when a privileged user next ran Chrome (although UAC would still mitigate the damage as this will still apply in compatibility mode).

The attacker would of course need access to the machine, and would need a perfect storm of misconfiguration to succeed. There are no vulnerabilities in the compatibility mode changes that I know of that would enable an attack on the client to succeed from the web where it would not normally succeed without compatibility mode.


is it possible to avoid hardware backdoors?

A key part of information security is risk analysis.

It is not possible to completely secure everything, everywhere, at every point in time.

Example, you download a file. Can you be aware that someone has tampered with it? Can you be sure someone hasn't inspected this content before you downloaded it? How much of a 'risk' is this for you?

On the case of the libreboot, while it may be open source, have you compiled it yourself? Do you understand what is going on? What is the risk of using default, "from the factory" firmware/boot loaders?

Depending on how paranoid or concerned you are about your own security, the only true way to have complete trust over a system is to build it yourself, with your own chips. This is unlikely to happen until individuals can buy and manufacture chips in their basement. There is implicit trust in what you use, and with anything such as a car. Can you trust the people who work on your car, or do you work on it yourself?

Backdoors that work at the hardware layer and inserted into firmware are hard to detect unless you are able to compare the factory's image to yours. While a joke, the story about a HP printer containing a modified chip and firmware is completely possible. How would a user be able to detect such a change? You may find this article of interest: https://en.wikipedia.org/wiki/Logic_bomb and this about the "joke" http://www.theregister.co.uk/2003/03/10/one_printer_one_virus_one/ .

Another assumption made is that open source = secure. This is not the case, as demonstrated by Heart bleed in the very popular open source OpenSSL library. Microsoft's implementation was not effected by such an attack, but is closed source.

Tor will guarantee "perfect forward privacy", but a destination must still be known. In theory, users can still be tracked through tor if the entry and/or exit nodes for your connection are compromised.


Private keys should exist only in one place. If you distribute the private key to "authorized users", then the "authorized users" have all access of the original, and cannot be revoked.

The correct method would be:

All devices share their public key, never their private key.
The public key is approved by the account holder.
Any changes logged should include the public key that was used, including the above approval process.
If you want data to be shared between nodes, but not let the server/a hacker have access to it, generate a random key, encrypt the piece of data with the random key, and store it; then, encrypt the random key with each public key in turn, and store those. Then throw away the random key. Each authorized user can grab the encrypted random key, decrypt it with their private key to get the random key, and use that to unencrypt the data.


Is it possible to trace fellow nodes on a DSL internet connection?

[What follows is one possible organization of your ISPs internal network. From my experience (~5 years ago), it is/was relatively common at small/medium US ISPs.]

Your computer talks ethernet to your DSL modem.

The modem is connected to a DSLAM (DSL Access Multiplexer). The DSLAM forwards your traffic (possibly through one or more routers) to a BRAS (Broadband Remote Access Server) that acts as the PPPoE server.

Your DSL modem runs a PPPoE client. PPPoE is "Point to Point Protocol over Ethernet". So your modem is talking PPPoE on the network side (as opposed to ATM, etc). The PPPoE is carried to the BRAS, where it is stripped of PPP and the IP is handed off to another router heading toward the Internet.

Here's a quick sketch:

The PPPoE server assigns an IP address to your modem. It is not a "proxy" in the sense that it is a web proxy. All it is really doing is wrapping the IP packets from the internet and sending PPPoE to your modem. (And the reverse for outbound traffic.)

With PPPoE, all traffic is forced out to the BRAS -- you don't have any "fellow nodes", there is no "LAN", you're basically on your own subnet. Sniffing will not do you any good -- there's no traffic for other nodes coming into your modem from the BRAS.

You can't get a network map because your traffic is encapsulated (as PPPoE) as it travels over the various internal nodes of the ISPs network. You might be able to enumerate other nodes that share your IP address block, but finding a "nearby" address doesn't mean that user is close geographically or network-wise. And, since your traffic will be going through the BRAS and possibly the router, your scan could land in the logs and prompt some uncomfortable questions from a network admin.

(Even if your ISP wasn't using PPPoE, it is likely that all of the traffic from your modem would be forced up to a router ("MAC Forced Forwarding"). This makes it easier for the ISP to enforce policies, including CALEA compliance and separation of subscribers from one another.)


Windows Honeypot user account for tracking laptop

Might there be some value in going the whole nine yards and instead of just having a dummy 'admin' account, using the hidden operating system functionality of truecrypt to run your own 'actaul' os thereby giving them the whole (unhidden) operating system to play with (which you have installed your tracking rootkit onto etc)? This way, you can really give them the impression of having gained access to somebody's private data (without having to mess around with faking much), install whatever rootkitesque tech you're going to for remote monitoring/control (maybe its just me but installing this kind of thing on my everyday os would make me nervous!) and be more sure of properly protecting your actual data.


Is it dangerous to show all the JavaScript functions in my web application?

To state it more directly:

  Is it dangerous that the attacker knows all the JavaScript functions and all the CSS styles (effects) ?

No, it is not inherently dangerous for an attacker to see JS and CSS. After all, the attacker or any other client must be able to see these files in order for the application to work at all!

It is your job to design your application so that an attacker who has complete access to the HTML, CSS, and Javascript code still will not be able to execute an attack (whether an attack on the server, or a "client-side" exploit like cross-site request forgery). Easier said than done, of course, but that is the goal.

Actually, good security would mean designing your app so that an attacker who has complete (read-only) access to the HTML, CSS, JS, the server-side scripts, the web server's source code, and the system's configuration still could not pull off an attack. Attackers can, in general, get access to all these things. But in practice, you can take measures to hide the server-side configuration and source code, and it will slow down someone who is not sufficiently determined. You cannot hide the HTML/CSS/JS and still expect the web application to work.