A no-login approach to authenticating a certain device, MAC-Address as password?

A MAC address is unsuitable for this for several reasons:

The MAC address can be changed freely by the user in software, and will change if the network hardware is replaced.
A wireless device broadcasts its address to everyone around, so it's hardly a secret.
MAC addresses are supposed to be unique, but in practice, they aren't.
A device with multiple network interfaces (say, a wireless card and an ethernet jack) will have multiple MAC addresses.

I'd look into something like client certificates, as mentioned by Dmitry Yanushkevich, or storing a unique token on the client as part of the account-creation process.


Internal network security policy for development environment

Yes, follow a iSMS such as ISO 27002, PCI DSS, Visible Ops Security, or similar.

Overlooked controls include 2FA authentication and TLS protection of developer repos (e.g., GitLab, Subversion, Atlassian, Perforce, et al) that conform to SSL Labs criteria, as well as other components of Application Lifecycle Management (ALM), such as tools for bugtracking, code documentation, code review, collaboration, et al. API keys are always at risk: developers accidentally leave these in their code, .git/.svn folders, etc. Be aware, have backups, and have a backup plan when all else fails.

... And remember, the best penetration testers in the world attack developers, not apps -- http://www.darkreading.com/attacks-breaches/tiger-team-member-attacks-developers-not-apps/d/d-id/1129737


Botnet tracing: Is SvcHost RemoteIP reliable or can it be spoofed?

how the RemoteIP associated with the SvcHost process can be spoofed

In TCP, you can't really spoof an IP address and use the connection. The TCP handshake requires a three way handshake where packets are exchanged between the two endpoints. If you have spoofed the remote IP address (i.e., written a fake or incorrect IP into the IP header) the handshake will fail. So, the bad actor client sends your servers spoofed packets (inbound SYN) your server replies with a SYN_ACK, but sends the SYN_ACK to some random place. If it arrives, the machine that receives it will wonder WTF this is doing randomly showing up there, and just discard it.

Spoofed IPs are useful for DDoS attacks (to hide the source), amplification (to bombard a target), etc...

But they are not useful if you're trying to get a connection and hide where you are.

  Is there a way to detect if these IPs are spoofed?

Not really. The only time I have seen that it was easy to detect spoofed IP requests (or what I surmise are spoofed IP requests) are looking at a firewall where there is a burst of inbound SYN packets, which get a SYN_ACK sent out, but an ACK is never recieved).

  Can an RDP connection be established via a spoofed IP?

Depends on your definition of spoofed IP. If you mean an IP address that is not associated with the attacker, then no.

If you mean an IP address that conceals an attacker, then yes. They can MiTM themselves, use VPNs, proxies, and a number of other technologies to obfuscate their actual IP addresses.

P.S. - One other thing that you need to be aware of in terms of "can a spoofed IP establish a connection" ... RDP uses crypto to secure the connection. This involves the exchange of keys in order to encrypt the data, which is another handshake that has to work. So, our TCP /IP setup requires a handshake. Key exchange for the crypto requires a handshake. You can't do all that with fake IPs. It has to be an actual machine that is ready, willing, and waiting to fulfill it's half of all the requests.

  How reliable is the remote IP in Resource Monitor?

It's reading the IP address from the IP header of the traffic. So, it's as reliable as that header is.


Any idea to prevent on this case of security breach on Windows 7

First of all, lock the workstations down with a BIOS/UEFI password. This is common practice for enterprise networks. If the device is yours, then do it yourself. This prevents systems other than Windows from booting. Also make sure you disable the XPE network OS loader.

At this stage, you cannot be certain the computer is 'OK' from now on since it was easy to install remote services from a bootable USB/Hiren's/Linux based memory OS. Reinstall Windows would be your next action. Wipe the drive on installation.
If you do not own the device, then tell the same thing to your IT team since they should have been aware of these actions.

Before reinstalling Windows, you can take a look at the local event logs. This should give you some more info on when the accounts were created.

In addition to the above and comments below, you might also want to question the knowledge of the people who are responsible for security (or IT). Every system administrator should be fully aware of the danger that comes with unprotected access to configuration.


UUID and Open_id in cookie 'good' enough?

Since the cookie isn‘t encrypted, the system is most susceptible to Man-in-the-middle (MITM) attack. The cookie can be intercepted on the network and then used to log in as the user. Putting UUID and OpenID in cookie without signing (via salted HMAC-SHA1) is bad. Actually, OpenID may and should be stored in database, while signed cookie will contain only "user id"—be it UUID or monotonically increasing integer, which is simply reference to database record in users table. It is how it is done in "real world": “log in” form sets such cookie, “log out” form removes it (ensure that they both work only on HTTP POST, and do not forget about CSRF protection).

Even though attacker will be able to intercept such signed cookie via MITM attack, he wouldn’t be able to change it. That is, you’ll be able to detect such tampering, and you’ll be able to refuse to accept such cookie.

Use of HTTPS will mitigate MITM attack, therefore use HTTPS + cookie signing.


Why do people still use/recommend MD5 if it has been proven weak since 1996?

To complement the good answer from @D.W.: for password hashing, MD5 is no more broken than any other hash function (but don't use it nonetheless).

The full picture: MD5 is a cryptographic hash function which, as such, is expected to fulfill three characteristics:

Resistance to preimages: given x, it is infeasible to find m such that MD5(m) = x.
Resistance to second-preimages: given m, it is infeasible to find m' distinct from m and such that MD5(m) = MD5(m').
Resistance to collisions: it is infeasible to find m and m', distinct from each other, and such that MD5(m) = MD5(m').

MD5 is thoroughly broken with regards to collisions, but not for preimages or second-preimages. Moreover, the 1996 attack (by Dobbertin) did not break MD5 at all; it was a "collision on the compression function", i.e. an attack on one of the internal elements of MD5, but not the full function. Cryptographers took it as a warning flag, and they were right because the actual collision attack which was published in 2004 (by Wang) was built from the findings of Dobbertin. But MD5 was broken only in 2004, not 1996, and it was a collision attack.

Collisions are not relevant to password hashing security. Most usages of a hash function for password hashing depend on either preimage resistance, or on other properties (e.g. how well the hash function work when used within HMAC, something which cannot be reduced to any of the properties above). MD5 has actually been "weakened" with regards to preimages, but only in a theoretical way, because the attack cost is still billions of billions of times too expensive to be really tried (so MD5 is not "really" broken with regards to preimages, not in a practical way).

But don't use MD5 anyway. Not because of any cryptographic weakness, but because MD5 is unsalted and very fast. That's exactly what you do not want in a password hashing function. People who "recommend MD5" for password hashing just don't know any better, and they are a testament to a Truth which you should always keep in mind: not everything you find on the Internet is correct and trustworthy. Better solutions for password hashing are known, and have been used and deployed for more than a decade now. See this answer for details and pointers.


Browsers silently adding trusted root certificates in Windows

In the default configuration for Windows XP with Service Pack 2 (SP2),
  if a user removes one of the trusted root certificates, and the
  certifier who issued that root certificate is trusted by Microsoft,
  Windows will silently add the root certificate back into the user's
  store and use the original trust settings

I guess if you didn't remove it yourself, you can add to the above, " if a trusted root certificate is missing, Windows XP will silently add it.

via http://www.proper.com/root-cert-problem/


Finding the cipher suites supported by a web server

Thomas Pornin has published a command line tool written in C# that does this, among other things. You can find the tool here. You should be able to easily modify this into a library.


How to properly implement pseudonymization

Just because a system administrator have access to the database doesn't necessarily mean that the administrator need to have access to all the data. You can encrypt the data to prevent the system administrator from having access to the data. If the encryption happens at the client side and only the users have access to the encryption keys, then you can design it so the system administrator would not be able to decrypt the data. Using public key cryptography, you can allow data entered by one user to be read by a different user, without the first user having to share their own encryption key to the second user.

Of course most real applications need the server to do some work with parts of the data, usually to allow searching the database, you'll need to rethink these aspects of the application. Perhaps, you can store a second hashed_name field so you can search based on the user's name without disclosing the actual name. Perhaps you can store a general location of addresses in plain text and have the full address encrypted.

You'll also need to consider if there are any data that can be correlated with other data to leak information even after encryption/hashing. For example, you may hash a disease's name so you can use the field for searching patients with that disease, but by correlating the frequency of occurrence of the hashed names can be correlated with publicly available data about prevalence of diseases to reduce the number of possibilities that each hashed names can be. You may want to consider whether such advanced attack scenarios would be in scope or to accept tree risk and limit the pseudonymization only to opportunistic attackers.

You can also enforce physical partitioning so that system A and B are managed independently by separate teams, running on separate hardware and resources (share nothing). This way, you ensure that no single system holds all the data and data leak will require at least two person from different teams to collude.


Identify Unique Computer through Tracking

Will hiding behind proxies protect you?

Using a browser-based VPN plugin can betray you if you have Flash, Java, or even other plugins installed. Anything that can get read/write access to your file system will betray your presence.

There has also been a recently-discovered exploit that affected users of private internet access, a VPN provider.

It's also not that difficult to track you online, even if you're behind a bunch of proxies. Why?

Browser-fingerprinting

This essentially allows anyone with access to a browser-fingerprint database to track your surfing habits, if you have Javascript, Java, and/or Flash enabled, or aren't using a plugin to randomize your values on page load. Even with a plugin that randomizes these values, Flash and Java will betray you, and Javascript can do so as well, but not to the extent of what Java and Flash can do.

Surfing with Javascript Enabled

Javascript is notoriously exploited, and there are always new vulnerabilities popping up. Anything that can execute remote code on your system is dangerous. D

Surfing with Flash Enabled
Become a victim of Java exploits, or even legitimate Java programs.

There are multiple tricks to reveal your network interface / computer hardware information. Unique serial numbers on devices are a thing, and this is one of the ways Microsoft attempted to thwart piracy, only to affect legitimate users the most.

Signing into services/accounts that you normally use, while surfing anonymously.

For example, keeping iCloud, Steam, Skype, or something else running, or even having Windows check for updates! These leave a huge crumb-trail.

Using browser plugins with read/write access.
Analyzing connection logs for recent activity. Metadata owns you.

User A connected to Proxy A at X time.
Proxy A connected to Proxy B close to X time at Y time.
Proxy B connected to Proxy C close to Y time at Z time.

Your VPN disconnected you at an inopportune time, and you reestablished connection to normal services under your real IP.
You are the only person in your neighborhood connected to TOR at that time.
SSH Fingerprinting. It appears that if you're using a mac and your SSH connection reveals your serial number, you can be tracked this way. My theory on Device ID correlation can be better explained here, but I believe this is a perfect example of it in action.

Browser plugins in general will only re-route traffic to and from the browser's requests. That's it. If you're playing a browser-based game, then sure, I don't see why not.

Desktop games will not be redirected unless the browser plugin does some weird tomfoolery that manages to install an application on your desktop which does this.

Your concerns

  some websites Trace your router's Mac Address and therefore identify your computer.

You can spoof your MAC address quite easily. If websites are getting your mac address, it's because you have either Java or Flash enabled. Javascript cannot do this without using an exploit.

  Now if I wipe my computer and install a new OS, browser etc and even get a new IP are websites still able to identify my machine? Like a unique Hardware ID or something?

Yes, Flash can enumerate your device information, and easily help track you this way.

  I have also heard Javascript is able to get your MAC address. and therefore be able to figure out if you're running a Virtual Machine or an actual Physical machine.

Not unless there's a drive-by download exploit. Javascript can't get this information on it's own.

Finding out whether or not you're using a Virtual Machine is also something Javascript cannot do, unless you're using a non-standard resolution. Then it will likely detect it as a potential Virtual Machine. Let's say for example you resize your VM. It will most likely show up in your browser as a really funky resolution that isn't used normally - at all.

  And I figured that using Chrome will make it even easier for Google to identify that I'm using the same computer right?

Of course. Google Chrome Incognito used to phone home. I am unsure if it still does, but I don't trust Chrome.

So how can I avoid being tracked?

You can't 100% avoid it (exploits come and go) without going to absolutely extreme lengths, but you can make it a lot more difficult.

VPN that kills the Host OS connection if disconnected.
Virtual Machine (Guest OS that is not Windows) with a web browser (tor is good, but slow) which doesn't have Java or Flash installed, nor Javascript enabled.
No plugins, except essential privacy plugins.

You'd probably have to disable images for good measure. From time to time, image libraries are exploited.
For better results, use a VPN inside the VM, which is already VPN'd through your main system.

And this may not help much at all. Why? Because when you connect to Windows Update with a legitimate copy of windows, they know about your unique key / account, and Microsoft logs every single IP address for that particular key  / account. This means you'll be associated with the first VPN connection, even if you're hiding behind multiple proxies and VMs.

But how does that help track? Every little breadcrumb counts, and anything that associates you with anything online can easily help the right people find you.

But what about Linux? Most distros phone home as part of an update process. Qubes is one of the few operating systems that I know of which won't do this.

There are so many different and creative ways to be tracked. Bottom line is, if someone really, really wants to find out what you're doing, there are so many different tools to do so.

So is there no way to remain anonymous online?

Take off your tinfoil hat. Reliably blocking yourself from advertisers is one thing, and not too difficult. 100% Blocking yourself from everyone and everything is only possible if the computer is powered off and unplugged.

If you're online, then eventually an exploit will get you. And if you're going to such lengths to protect your privacy, you'll attract the attention of those infinitely your greater.


Are encryption keys wiped from RAM before hibernate, or how to do it (Luks and Truecrypt)

I am wondering when I put my laptop to hibernation if the encryption keys are wiped from the RAM before the computer is shutdown?

No because the because the master decryption keys are kept in DRAM whatever the encryption tool you use.

  or if I have to wait a few minutes to be quite immune against cold boot attacks?

Some authors stated that hibernation during 5 minutes or more makes the machine immune but more authors proved the opposite, including from the article I mentioned below, there is an answer to this question that confirms the no:

  Our results show that simply locking the screen of a computer (i.e.,
  keeping the system running but requiring entry of a password before
  the system will interact with the user) does not protect the con-
  tents of memory. Suspending a laptop’s state (“sleeping”) is also
  ineffective, even if the machine enters screen-lock on awakening,
  since an adversary could simply awaken the laptop, power-cycle it, and
  then extract its memory state. Suspending-to-disk (“hibernating”) may
  also be ineffective unless an externally-held secret is required to
  resume normal operations

An other quotation says hibernation is even more vulnerable since other methods than cold boot attacks:

  If people use hibernate or sleep mode, or lock the keyboard, they are
  potentially vulnerable in other ways. Just bring the computer back up
  to the login prompt, and start attacking the ports looking for an
  unpatched vulnerability. So a computer that is not completely shut
  down effectively bypasses the protection of full disk encryption --
  even without the cold boot memory attack.

You said:

  Technically I guess it is complicated for the encryption software to
  do that even if it detects that the laptop is going to hibernate,
  because if it alters the memory before it is copied to the disk then
  the encrypted volumes won't be restored on resume.

Yes, because there are other processes that continue to run.

The rest of your question are subject to more efforts and analysis. I can not answer them.

It is proven that:

  Ordinary DRAMs typically lose their contents gradually over a period
  of seconds, even at standard oper- ating temperatures and even if the
  chips are removed from the motherboard, and data will persist for
  minutes or even hours if the chips are kept at low temperatures

So unless the RAM of your machine is old, you have not to worry about this issue.

This is for the short answer. As the posts of StackExchange websites are intended to last, I forward you to read a more detailed answer to your question that I do not want to reproduce here.

Always quoting from the answer I linked to, you can shut down your machine safely:

- Keep secure data in True Crypt cascade algorithm encrypeted file
-  Use Serpent

- Create a script to handle shutdown:

           truecrypt /wipecache
           shutdown -h now

  /wipecache ensures that no vulnerable data remains in RAM after
  shutdown. If someone will perform Cold Boot Attack they will have
  access to your System at best. They will not have data stored in a
  separately encrypted file.


PHP & MySQL encrypting data that I need to decrypt at some point

The purpose of your application is to store a secret and reveal it to an authorized user at the right time. This doesn't work without being able to decrypt said secret. I am afraid that any solution where your organization is completely unable to access the secret is not going to work. So the only security practice which is going to protect you from the worst case scenario is the obvious one: "Don't have any security holes in your application."

However, encrypting data at rest in the database can still make sense if you want to compartmentalize knowledge of different departments in your company.

For example, if only the application server admin has access to the decryption keys used in the production environment, then you can grant any database admins and developers read-access to the production database without having to worry about them stealing any pins. The majority of day-to-day issues will be solvable without requiring the pins in clear-text. Just keep in mind that there will still be situations where in order to troubleshoot a problem someone must decrypt a pin in the production database. So make sure that your processes allow an exception for these situations.

This, of course, only applies if your organization is actually big enough for such a compartmentalization to make sense. When you are a small business where DBA, server admin, developer and security manager are the same person, all of this is pointless.

It might also help in those situations where unauthorized people gain read-access to your database (for example through an SQL injection or database server misconfiguration) but not to the server configuration where the decryption key is stored. But remember that this is just a limited subset of possible attack scenarios.

But in any case, be careful not to overengineer on your at-rest data encryption. The fancier your solution, the more bugs it will have. And the more bugs it has, the more situations you will have where people are forced to look at the decrypted data in order to fix said bugs.


What OS should I use for sandboxing/running viruses designed for IoT devices?

The only thing I would be aware of is CSR 1000v which can be run in VMWare.  Try following these instructions.

https://techandtrains.com/2014/01/09/installing-cisco-csr-1000v-in-virtualbox/


Yeah, you have risk exposing the .htaccess file to other user which are not in your trust circle although you are using php in cgi mode but I am not sure how capable are other user out there. For example rule like this expose your php code in text.

<FilesMatch "\.php$">
    SetHandler text/plain
</FilesMatch>

So what I suggest is don't give full permission to .htaccess only give permission to module which are requested or necessary.

For example don't allow modules  such as mod_mimes, indexes etc to other user.

Don't use

AllowOverride All

Instead mention module which you want to permit

AllowOverride AuthConfig mod_rewrite

Hope it helps.


Which keystore type is good for java / Tomcat based applications

My understanding is that you need to use a Java KeyStore (JKS) object for in-memory handling of certs and keys anyway. The fact that keytool does not know what to do with a P12 is evidence of this. The question is about how you store it on disk.

Both JKS and P12 files use strong encryption. P12 is needed if you want to share keys and certs between a java-based application (ie Tomcat) and a C or C++ application (maybe using openssl under the hood). If your stack is entirely java, then there's no reason to have each process disassemble the JKS into P12 files, and then have each process re-assemble P12s back into a JKS.

Think of P12 as the "Export to PDF" of the certificate world.


Is there an original information source linking output of Qualys SSL report to settings in nginx and Apache configurations?

I think you're asking how to map the openssl ciphers list configuration that you can supply to Apache and to Nginx to the IANA TLS cipher suite list.

openssl have a list that translates cipher suite names between their standard names used in RFCs (and by Qualys tool) and the names used by openssl.

You should take advantage of openssl's ability to generate longer list of cipher suites from shorter names, and specify a succinct configuration like EECDH+aRSA+AESGCM:EDH+aRSA+AESGCM:EECDH+aRSA+AES:EDH+aRSA+AES that makes openssl generate this:

> openssl ciphers -v 'EECDH+aRSA+AESGCM:EDH+aRSA+AESGCM:EECDH+aRSA+AES:EDH+aRSA+AES'
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384   TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES256-SHA384     TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)    Mac=SHA384
ECDHE-RSA-AES256-SHA        SSLv3   Kx=ECDH     Au=RSA  Enc=AES(256)    Mac=SHA1
ECDHE-RSA-AES128-SHA256     TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)    Mac=SHA256
ECDHE-RSA-AES128-SHA        SSLv3   Kx=ECDH     Au=RSA  Enc=AES(128)    Mac=SHA1
DHE-RSA-AES256-SHA256       TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)    Mac=SHA256
DHE-RSA-AES256-SHA          SSLv3   Kx=DH       Au=RSA  Enc=AES(256)    Mac=SHA1
DHE-RSA-AES128-SHA256       TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)    Mac=SHA256
DHE-RSA-AES128-SHA          SSLv3   Kx=DH       Au=RSA  Enc=AES(128)    Mac=SHA1

which is basically what you want (as long as you don't use ECDSA certificates and made sure your DHE uses a good 2048 bit group).


Symmetric encryption - given plain text, produce cipher text without key

This depends on the block cipher mode that's used and/or any message authentication that the system may do. But plain old encryption-only modes likes AES-CBC and AES-CTR are vulnerable to malleability attacks, where an attacker who can get some ciphertext (or even better, ciphertext/plaintext pairs) is able to modify it to produce a message some aspects of whose decryption they can choose. There are practical examples of this, like the EFail attack:

The attacker changes an encrypted email in a particular way and sends this changed encrypted email to the victim. The victim's email client decrypts the email and loads any external content, thus exfiltrating the plaintext to the attacker.
[...] Because of the specifics of the CBC mode of operation, an attacker can precisely modify plaintext blocks if she knows the plaintext. S/MIME encrypted emails usually start with "Content-type: multipart/signed" so the attacker knows at least one full block of plaintext as shown in (a). She can then form a canonical plaintext block whose content is all zeros as shown in (b). We call the block pair X and C0 a CBC gadget. In step (c), she then repeatedly appends CBC gadgets to inject an image tag into the encrypted plaintext. This creates a single encrypted body part that exfiltrates its own plaintext when the user opens the attacker email.

None of this requires knowledge of the key.
The modern solution to this sort of thing is the use of Authenticated Encryption modes (aka "AEAD"), for example AES-GCM, that contain additional protections to detect and reject forged ciphertexts. But the use of this and other similarly modern algorithms is still not universal—for example EFail is an attack on S/MIME and PGP email which are older technologies but still widely used.


What would HTTP/2 TLS encryption provide?

"HTTPS" is "HTTP-within-SSL" (now, SSL evolves under the name "TLS" but that's the same thing). HTTP/2 is nothing special here, except in that it makes TLS somehow mandatory; in other words, when (if) HTTP/2 becomes an actual thing, all sites using it will be HTTPS sites.

From the TLS point of view, these are just bytes. TLS does not know or care whether the transported bytes actually encode HTTP/1.1 requests, HTTP/2 requests, or anything else.

The "CA system" is linked to TLS, not to HTTP. HTTP/2 changes nothing in that respect. What could "ditch the CA system" would be DANE, and this would apply equally to "normal HTTP" and HTTP/2 (and it would not really remove all CA, despite the propaganda; it would merge CA with domain registrars, which would more amount to a change of players rather than removal of the CA concept).


Does Yandex browser have known records of snooping for user data & passwords?

You can see in the documentation how the password feature works:

Yandex Browser Personal Data Protection - Passwords (New)

  After you enter your password on an important website, Yandex.Browser creates a fingerprint (hash) for it and saves it in its database. When you enter passwords on other websites, the browser compares their hashes with the ones in its database. If there is a match, the  icon will appear on the right side of the SmartBox to warn you. The browser will ask you to confirm that you want to use the same password on several websites before sending your password to the server.

Yandex Browser Personal Data Protection - Passwords (Classic)

The best you can do now, is to delete the whole activity in your Yandex Browser and verify each step of the settings, so you could verify that is configured to NOT remember any password that you enter.


Mobile App Security vs. Traditional PC Desktop Security In The New Era

No.

You should not click install the app. The process I go by is quite simple:

What is the app doing?
What are the permissions?
Is that permission really needed?

Now let's look at a simple example:

What is the app doing? Eg: Simple text editor.(Read/Write stuff from/to files)
What are the permissions?

Case 1:
Permissions: Read/Write files. Access microphone.
I am tempted to accept this one. Although this one asks for microphone it might use it for text/to speech. If it does this it should mention it in the description. Even if it does that, it could still be spying on you. But none the less, the app might be innocent.

Case 2:
Permissions: Read/Write files. Access microphone. Access contacts. Access network connection.
This one would make me have second thoughts. As said before, the app should be a simple text editor. There's no need for a simple text editor to use contact and connect to the internet.

Bonus:
If you want to go really hardcore, what you should do is reverse engineer the application. Look at how those permissions are being used within the app.  Where is my app connection to the internet. What is happening with that connection. where is the microphone invoked and where is the recorded sound going.


how secure is rsa encryption for a web login without https?

It will be somewhat secure, but not nearly as secure as https, aside from the credentials all other data is unencrypted. If you plan on using it on public (open) networks, I would recommend setting up a proxy as described here. Even with a self signed certificate it will be a lot more secure.


Is it possible to make John the Ripper work with only those entries that are in a wordlist (e.g. rockyou.txt)?

If you are using kali Linux then  you can  invoke john with the following command .

john --wordlist=/usr/share/wordlists/rockyou.txt /{path to hash file}

Suggest you to go through the documentations of john openwall.com/john/doc/RULES.shtml for other additional conditions like specifying the format , type single or multiple etc.
There are many blog posts on the internet that provide a walkthrough.
Anyways the above command is the answer to your question.


How is Tor secure despite being open source?

I'll take a crack at explaining this without technical jargon.
Lets say you want to send a nasty letter to someone, but you'd rather not deliver the letter in person for fear that they might get angry with you.
You can ask a courier to take the letter from your house, and deliver it to the recipient, right? That works, but has the problem that the courier knows both identities, and an evil courier could snitch on you.
You could use two couriers, and instruct the first to pass it on to the second, and instruct the second to pass it on to the recipient. That almost works, because now you are the only person that knows both endpoints to the conversation. Courier A knows you and courier B, while courier B knows courier A and the recipient;
You --- A --- B --- Recipient

And just to decrease the chances of getting a bad circuit (when all couriers are evil and working together), ToR uses 3 couriers, so add a 'C' to that diagram in your head.
There is one problem remaining; how do we deliver the instructions to each courier without revealing our identity? If you wrote 'pass to B' on one piece of paper, you can give that to courier A alongside your nasty letter, but any instructions you send along with it, A can also read, and will therefore know the identities of everyone on the circuit.
ToR solves this final problem with repeated encryption, encrypting the message and instructions repeatedly, once for each courier. In terms of our analogy, this is what you do;

Put your nasty letter in a red box alongside a piece of paper saying 'pass to recipient'.

Lock the red box with the key belonging to courier C.

Put the red box inside a blue box alongside a piece of paper saying 'pass to C'.

Lock the blue box with the key belonging to courier B.

Put the blue box inside a green box alongside a piece of paper saying 'pass to B'.

Lock the green box with the key belonging to courier A and pass it to him.

If you follow this through, you will see that none of the couriers can ever have knowledge of the full circuit, and there is no way for the recipient to find out that you sent the nasty letter.


This is not exploitable.

You cannot escape the string because quotes are encoded. (" -> &quot;)
You cannot escape the script tag context because angle brackets are encoded. (< -> &lt;)
You cannot create anything but http[s]:// URLs because the beginning of the string is checked. It does not matter what you append after the protocol part, you cannot turn this into a data: or javascript: URL afterwards.

There are other tricks you could try but they are implementation-specific. There is no evidence they would work in this case, so these are just a few examples to give you an idea:

Maybe the filter stops after a NULL byte? (e.g. http://%00"<>...)
Maybe for some reason unicode variants work? (e.g. U+FF02: ＂)
Maybe other encoding schemes work? (e.g. \x22 instead of ")
etc.


Is XSS a server-side or client-side vulnerability?

In a cross-site scripting attack, the malicious script is run on the client, but the actual flaw is in the application.   That doesn't necessarily mean that it is a strictly server-side vulnerability, in that the flaw could be in the application's JavaScript, but generally, it is indeed in server-side code, and always in code that is delivered by the server.

There are client-side mitigations, such as the XSS-Protection that is now built into major browsers, or plugins that prevent the execution of JavaScript, but ultimately XSS is a web application vulnerability, and needs to be fixed by the application developers.

I should mention that there is another form of XSS that exploits neither flaws in the client (the browser) nor flaws in the server (the application) but flaws in the user.   This is often called Self-XSS, and exploits the willingness of a inept user to execute JavaScript he has copied and pasted from the Internet and into his browser's developer tools console, solely on base on the promise that against all hope, it will magically allow him to read his ex-girlfriend's Facebook posts despite the fact she has unfriended and blocked him.


Are there any security related issues if we allow domain users to change their wallpaper and screen saver?

No, there are absolutely no security issues with changing a system's screensaver or wallpaper, at least if you are using the defaults. A company may enforce such a policy because they do not want people to display offensive or controversial material, or because they want to standardize a given look. Remember also that screensavers come from executable files, so there is a security reason to disallow people from downloading and installing arbitrary screensavers from the web.


Yes, this is a major security vulnerability, but that has nothing to do with XSS.

For example, an attacker might render a fake log-in form and trick your users into handing out their passwords.

The SVG can also be used for a clickjacking attack against yourself or sites which trust you, even if state-of-the-art protection is in action. Standard techniques like the The X-Frame-Options header usually just check the top-level browsing context, and that is your site. So an attacker is likely to be able to embed other pages of your own site or partner sites in a frame and then trick the user into taking actions on those pages.


For malicious (really any) data to modify your computer, it is required that the data is interpreted at the target location. The only scenario I can see - and it is a far fetched one - is that some "smart socket" that may perform some action based on the quality or fluctuation on the network. Say that you, as an attacker, force the power fluctuation to perform the fluctuation-action, you can call this malicious activity. Far fetched.

Edit: As smart phones' charge connectors double as communication points, changing the roles is easy. If the phone charges from a computer, i.e. through USB, sending data instead is probably trivial. Of course, again, it's important that the phone interprets and acts on the incoming data.


how to determine the cipher suites supported by a SERVER?

I use this nmap script, it's convenient and gives scores similar to Qualys SSL Labs:

https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html


Why should the *nix system administrator account (root) have a strong password if remote root logins are disabled?

If you follow the principle of least privilege and layered security you have to make sure that on each level of a system you implement strong security measures. At each level means you do not make any assumptions about how easy/difficult it might be for an attacker to get to that level in the first place.

When you write

  As a consequence of the above, to gain root access remotely, you first
  need to break into an ordinary user's account, then additionally
  escalate to root access. In this case, the password on the root
  account only protects against a password-cracking attack on the root
  account, not any of the other multitude of possible ways for an
  attacker to escalate privileges.

you are perfectly right, but why do you say

  only protects against a password-cracking attack

? A strong password eliminates this very attack vector even if there might remain other attack vectors to escalate privileges. The other attack vectors need of course to be taken care of as well.


Would a multilingual Diceware password be more secure than a monolingual one?

Using different languages together would increase the entropy, however that would defeat the main objective of Diceware - which is easy to remember passphrases (that are also secure).

Each Diceware word adds ~12.9 bits of entropy. The NIST recommendation for secure passwords is to use at least 80 bits of entropy. Therefore it would be much easier to simply use 7 different words from the Diceware wordlist and have the same security.

As a guide, it would take a determined attacker 109,527.95 years to run through the whole keyspace of an 80 bit password, which would give an average cracking time of 54,763.975 years.


How can I prevent my database from being compromised if my CakePHP app is compromised?

If the application is compromised, the database is compromised even if you can conceal the credentials.  The DB credentials should only be valid from the application server's IP address and if they have compromised the application server that much, they can simply alter the application code to do whatever they want if you did somehow manage to protect the credentials.

The key thing is to make sure that the credentials only work from the server and that the user that the application uses can only impact the application itself in the ways the application needs to interact with the DB.

Really, it is very hard to conceal the credentials any better anyway.  You can use something like a TPM, but then the application needs a way to get access to the TPM.  Unless you don't give the application authorization without the user providing credentials for the DB itself, then you have to store them.

Depending on how the sensitive data is accessed, you may also be able to use user based encryption.  With user based encryption, you use the user's password to derive a key which is used to encrypt a secure key.  That secure key is then used to unlock a keyring which contains keys for accessing any records the user has access to.  Since the user's keyring is only accessible when the user is logged in, it reduces the threat of an offline compromise where both the application server and DB server are compromised.

This does put some limits on what can be done while the user isn't logged in, though you can have a sproc that has access to do some decryption operations using a master key ring that only is available in the DB server, but you'd have to be very careful to lock that functionality down tight to prevent it being abused.  (Rate limits on custom sprocs for each type of query you need against the secured data for example.)


Symmetric Cryptography means that the key used for encryption is identical to the one used for decryption. This means that in order for two parties (Alice and Bob, as an example) to communicate, they need to share this key somehow.

Using purely symmetric cryptography, this is not possible. In order to send the key, one would need to encrypt it. For that, a key is necessary, and the problem begins anew.

How can symmetric keys be exchanged?

One way would be to use asymmetric encryption. This can either mean using an algorithm which generates a shared key, or by simply encrypting a key and sending it to the other.

Another possibility is out-of-band exchange, meaning that keys are exchanged through a different method than is used for communication. This could mean in person, via letter, on the phone, over the radio, etc...

None of these would be practical for certain ways of communication. For example, communication with a web-server would be completely impractical if I had to call them beforehand for them to transmit a 128-bit AES key to me over the phone, and it would suffer from the same problems as we had initially, since that call would not be encrypted.


How to detect/list rogue computers connected to a WIFI network without access to the Wifi Router interface?

I'm a bit confused why nmap would not be the weapon of choice, an nmap ping sweep would be my very first step. However, an alternative is you could simply ping the broadcast address and then do an arp -a. If the network is a /24 as most wireless networks are, say 192.168.0.0 with a 255.255.255.0 subnet mask, then pinging 192.168.0.255 will get all the systems on the network to respond and the arp table will show all devices on the network. An arp -a will list all those systems.

Really the best way to go about preventing unauthorized use would be to change the password and change the wireless security to WPA2 instead of WEP or WPA. That will kick any freeloaders off and make it much, much more difficult for anyone to break the key again. There's very good reasons for doing this as it will prevent your relative from being accused of software piracy and having a massive legal headache.


Does Windows Device Encryption use a new key to encrypt each time?

"Device Encryption" in Windows is a user-friendly name for Microsoft's "BitLocker Drive Encryption", first introduced with Windows Vista and updated with newer Windows releases.

I am wondering: after the format and reinstall, is a new key generated for the Device Encryption?

Yes
When BitLocker is "turned on" (enabled), it generates a new encryption key from the system's cryptographically secure pseudo-random number generator (CSPRNG), which is software that takes a large number of of different inputs, including many transient ones that are not practically controllable or repeatable, and mixes them together constantly such that at any time its output will appear totally random. The output of a CSPRNG should not ever predictably repeat, and certainly won't just because you performed a full reinstallation of the OS!

What if I delete a file, turn off Device Encryption, and reenable? Can my deleted file be recovered without the original recovery key?

I don't know, but it may depend on BitLocker mode
There's two points of consideration here: is the old key gone, and did the deleted file get decrypted-and-re-encrypted?
When BitLocker is turned off (or paused), a key is written to the disk in plain text that can be used to recover the master encryption key. This plain-text key will remain until BitLocker is fully done decrypting the drive (if turned off), or is resumed (if paused), at which point the OS attempts to securely wipe that plain-text key from the storage. If an attacker steals the machine before BitLocker is done decrypting, they'll be able to read the still-encrypted data by using that key. I don't know what happens if you turn off BitLocker and then try to turn it on again without giving the OS time to decrypt the disk first; it might just start re-encrypting with the same master key, but set up new "Key Protectors" (the ways, such as boot-time passwords or recovery keys, that the master key can be retrieved to unlock a BitLocker'd volume). That would not be ideal from a security perspective, but with TPM-only mode (I believe most cases where you see BitLocker as "Device Encryption" will be BitLocker in TPM-only mode) there's no user-facing protectors to rotate so it's possible they don't bother rotating the key either. Certainly that would be faster than fully decrypting and re-encrypting with a new key.
However, if you allow the system to fully decrypt before turning BitLocker on again, it will generate a new key. The old one won't be available anywhere for re-use.
For deleted files in particular, this is an interesting question because BitLocker can operate in two modes, and I don't know which one you'd be seeing. The fastest way to encrypt a disk, used by default on new installs, is to encrypt only the in-use space. BitLocker can optionally encrypt all space instead, which takes longer but means previously-deleted data will not be recoverable without the key. Also, BitLocker does not automatically decrypt files upon deletion no matter the mode; that would obviously be insecure. Your question, however, concerns an interesting edge case: if you have BitLocker enabled only and delete a file, and then turn off BitLocker, does it bother to decrypt the free space? I don't know. If it does, then YES, your deleted file would be recoverable (assuming no overwriting, of course) without the old key; either it would still be sitting around in plain text (if you turned BitLocker on again in "used space only" mode) or it would be re-encrypted with the new key (if turned on again with free space also encrypted). However, if it doesn't - if BitLocker never bothers to decrypt "free" space when turning off - then the deleted file's data would be permanently unrecoverable as soon as BitLocker finished decrypting and wiped the old key.


For testing and developing I allowed all Headers. ...

It is not very clear what you mean here (maybe be more specific and do not only dump the config) but...

 Header set   Access-Control-Allow-Origin        "*"
 Header set   Access-Control-Allow-Credentials   "true"

It is definitely not a good idea to allow cross origin access from everywhere. And it is even worse to combine this with sending cookies and other credentials.

With this loose restrictions an attacker could use XHR requests do access a site with the stored credentials of the user (i.e. session cookie), change data with permissions of the user (classical CSRF) and even read the response back (what classical CSRF can not do). For instance if you would deploy this code for a company internal application an outside attacker could use the internal users browser as a trampoline to fully access the application and read the content and all with the identity of the currently logged in user.

Such XHR based attacks could be delivered when the user visits the attackers site and such a visit could just be triggered from within an advertisement delivered by any of the ad networks.

Apart from that:

Header set   Access-Control-Allow-Methods     "...HEAD, HTTP, HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2, OPTIONS, ORIGIN, ...

I have no idea what you are trying to do here but methods are GET, POST, HEAD... and not HTTP/0.9, HTTP/1.0 etc. I really recommend that you take a closer look at how CORS works, what the headers mean and what the security implications are.


How does a "fake" network-adapter steal credentials?

The attack you read about is probably PoisonTap. Basically it works by the USB device being a small computer which emulates an USB network adapter and provides IP address and routes so that most of the network traffic of the attacked computer gets send to the USB device.

Getting credentials this way is possible since browsers continue to run if the screen is locked and they continue to update sites in the background. PoisonTap provides such "site updates" and includes links to even more sites inside the update so that lots of sites gets accessed. And it provides the content for these sites too etc. The requests to the sites where the user is currently logged usually include a session cookie which often can be used to impersonate the user. Sometimes requests also includes the original username and password credentials, for example if basic authentication is used by the site. And, if the victim is using a password manager which automatically fills in credentials the attacking USB device might return pages which include login forms and some Javascript and thus extract the automatically filled in credentials.

Note that this works only for HTTP and not HTTPS since the attacking USB device does not provide trusted certificates for the sites in question. Still, not all sites use HTTPS and some times will provide the session id also if the target URL is HTTP only (i.e. no secure flag set on cookie).


How one would typically detect systems vulnerable to “NULL Session”?

As @Philipp noted, it's not exactly clear, but if you are talking about a windows authentication null session, there are a lot of resources out there. Basically, it means you get access to some system resources shared on the network without needing real credentials to authenticate (log on). This existing definition is pretty good:

A remote session is created when a user logs on to a computer remotely using a username and password that has access to system resources. This is accomplished through the Server Message Block (SMB) protocol and the Windows Server service. These connections are entirely legitimate when proper credentials are supplied.

  A null session comes into play when a user makes a connection to a
  windows system with no username or password. This type of connection
  can not be made to any typical windows share, but it can be done to
  the Interprocess Communication (IPC) administrative share. The IPC
  share, as the name alludes to, is used by Windows processes (via the
  SYSTEM username) to communicate with other processes across the
  network. The IPC share is used exclusively by the SMB protocol.

  Using the IPC share with no credentials is typically reserved for
  programs communicating with one another, but there is nothing to say
  that a user could not connect to a machine via the IPC connection
  instead. This would not allow for unrestricted access to the machine,
  but will allow for pretty extensive enumeration that could aide an
  attacker.

This site also explains how to test for this using net use command. There are also some purpose built tools for this you can find.


Which block cipher for a very short (40-bit) message?

The generic name for that kind of stuff is format-preserving encryption. The Thorp shuffle is a nice candidate, provided that you use an adequate round function (e.g. truncated output for a cryptographically secure hash function) and enough rounds, as indicated in the paper.

That being said, with 1 million cycles on an 8-bit computer, it may be hard to run, say, a 64-round Thorp shuffle with a truncated SHA-1 as round function.

Unfortunately, there is no standard, well-studied block cipher with short blocks and good performance on small architectures. On the other hand, your attack model states that attackers won't try really hard, so you don't need absolute crypto-grade security; a construction which is academically weak may still be strong enough for you.

I suggest you skim through this page that lists "lightweight block ciphers" with some analysis. Some of them offer 32-bit block size. What you need is such a block cipher, such as there is a known attack on a reduced number of rounds, thereby indicating that some cryptographers tried to break it, and did not succeed for the full cipher. From a cursory look, at least KATAN, KTANTAN, SIMECK-32, SIMON-32 and SPECK-32 match these criteria; RC5 might also be usable with an adequate number of rounds.


Know LastPass fishing apps? Ways to protect?

First installing extension is not a harmless operation. Common usages say:

  Once you have installed an unwanted software on your computer, it is no longer your computer

But the attack should be slightly more complex than what you describe (after all Lastpass is a well known security solution). The master password that you type into the password extension is only the password of the keyfile used to decrypt locally the content of the vault stored on Lastpass server.

So the fake extension should have to:

either to install itself between the browser and the real extension - not that easy
either to fully reproduce all the decoding operations of the true extension - indeed possible but still a fair amount of word - meaning

locate and unlock the keyfile with the master password
download the vault
decode the vault

Such an extension would be a major attack against Lastpass, and as such with a great risk of being identified and de-activated soon.

Following in only my own opinion:

This is still a serious threat that should be considered, mainly in case of a targetted attack, meaning if the attacker can manage to activate his software only on a small number of machines to limit to risk of being identified soon. That assumes that the attacker is a strong organization and you as the target represent a high value because in any other case the ratio gain/cost is low and the whole operation does not worth it.

Anyway, the rule here is that Lastpass can allow you to securely use passwords from a local machine, as long as the local machine is secure. If the local machine is compromised - and having an unwanted extension in your browser is a serious compromission - anything can happen (keyloggers, theft or suppression of files, etc.)


I would go the exact opposite way. Put the code on github, let people fork it, send pull requests, change the code. It evolves. If you made a critical mistake, someone will notice and inform you.

And use TLS. There's a great community behind it, there are bugs, but they are so obscure most of the time that we mere mortals don't need to be worried. Misconfiguration, programming errors, logic errors and code injections are way more prevalent and exploitable than TLS bugs.

If you want to implement replay protection, use an increasing nonce. This way the server will only need to save one value - the last used nonce, and the client will have to increment it before every request. It does not need to increment by one, it can be incremented by any value. In some API's I use, the nonce is the Epoch (plus milliseconds).

Quoting Antoine de Saint Exupéry:

  It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove.

API's are meant to be simple. Don't add any mechanism if you don't need to. Adding components increases complexity, reduces performance, and it's one more thing you need to update from time to time. Keeping only essential parts reduces this burden.


Client-Server Authentication Security Issue

You cannot trust the client, and your client-server authentication cannot work.

Any hacker can run an unmodified version of your software, capture all data he needs, and change the client executable later. Using an interception proxy will allow him to change the request and use the original hash of the file.

Or he can use a valid key, download the missing parts, patch the executable to include that parts, and skip the authentication.

Using TLS does not help, not even certificate pining. As he is in control of the connection, he can even change the client executable to allow his own certificate to pass the checks.

He will be able to authenticate no matter what. Your protections are only speed bumps, not road blocks. List of broken DRM schemes includes Sim City, Diablo, Battle Field, Doom, Assassin's Creed, Dishonored, you got it.

If even Ubisoft, EA, Sony, Microsoft, Konami and others could not deter attackers, you will probable be unable to deter them too.


Testing Web Application Firewall Configuration (ModSecurity)

Much though some vendors would like you to think that a WAF is - (a) a requirement and (b) a black box you can dump down in front of your webapp to protect it from all possible attacks - it really doesn't work that way. A WAF configuration isn't binary 'secure' or 'insecure'; it will just be more or less effective at addressing particular forms of attack.

So you need to have an idea of what attacks you're trying to prevent so that you can test those. Are you attempting to guard against malformed HTTP requests? Try some. Are you trying to counter invalid UTF-8 sequences? Test it. Is there are a specific application vulnerability that you're trying to block at the WAF as a temporary measure because you can't get the application fixed yet? (This is what WAFs are really good for.)

(Are you trying to guard against application-level SQL injection by filtering out the word 'SELECT'? Then you're pretty much wasting your time. There are a lot of rules like this in the mod_security CRS which are pretty much entirely bogus.)


Is receiving an OTP via email any more secure than receiving it via SMS?

The worry is that 2FA protects you in cases where your passwords get leaked. The 2FA is a mitigating control to prevent people from abusing that password. However people often re-use their password across multiple websites, including their email and most people do not protect it with 2FA.

This means that if your password leaks, there is a higher likelihood that someone will be able to get your OTP from your email address than from a text message.

Hardware tokens and OTP generators are still much more prefered over SMS or email.


Is SSL secure enough for a REST API - has anyone used PGP or AES to encrypt the actual data inside SSL?

Yes, there are situations where layers of encryption make sense.  Here is one specific example:

SSL may be legitimately decrypted by at interim points; it is not always end-to-end:

Akamai may decrypt and re-encrypt traffic for which it's providing content delivery.
Prolexic wants their clients' SSL keys so that when they're called upon to protect against a DDoS they can open up packets and make smart decisions about what to permit and what to drop.
An IDS/IPS may be configured with private keys in order to decrypt traffic for analysis, and you want to protect sensitive data from being logged there.
Even internal to a business, SSL may be decrypted at an SSL edge gateway for performance reasons and passed unencrypted on internal networks.

Someone's going to jump up here and say "You shouldn't use SSL that way!"  Agreed.  It just happens to happen in the real world a non-trivial amount of the time for reasonable reasons.

My company has an API that does what you describe.  XML-over-HTTPS transactions have specific sensitive fields encrypted with public key encryption.  The SSL can be decrypted by interim hosts for reasons such as those I've listed above without exposing the sensitive information.  It's a smart solution to a real problem.


Why does HTTPS not support non-repudiation?

I thought HTTPS would prove that a given content actually came from the origin, by having its contents always signed before transfer.

Since "content" is sent in both directions, providing non-repudiation would require some cryptographic identity capable of signing on both sides of the communication. But TLS actually only requires some proof that the server is the expected one (to protect against man in the middle attacks). And this proof does not even need to be backed by a cryptographic identity, but can also be backed by some shared secret (i.e. PSK).
And while in most cases of TLS a certificate is used on the server side, there usually is no certificate on the client side. This means that non-repudiation could not work in both directions. Requiring some client side certificate would make the practical use of TLS much harder, since not only would each browser need to come with its own trust store as is done currently but also each user needs to have a personal certificate.
On top of this it is questionable if users would really want to have non-repudiation for everything they send. This is probably contrary to the quest for more privacy and anonymity. There is a reason protocols like PGP or S/MIME offer both encryption (including integrity) and signing (non-repudiation) separately.
In short: non-repudiation makes the protocol and the necessary infrastructure more complex and might not be even wanted in many cases. TLS therefore sticks with protecting the communication only, which is enough for most use cases of TLS. If non-repudiation is actually wanted or required (and often it is not) it can be added separately.


How do I verify Quad9 is working and that I am benefiting from its
  features, especially encrypted DNS and DNSSEC?

Did you specifically install, enable, and configure those features? Also, what protocol for encrypted DNS did you set up (DNS over TLS, DNS over HTTPS)? Pointing your router's DNS setting at a different server doesn't automatically activate new protocols and features.

  Do I need to use a client on each computer/device, or does configuring
  my router make it work for the entire network?

That depends, are all of your devices pulling DNS settings from DHCP, and is the advertised address that of the router itself? It will depend on the individual device. If you cannot change settings on a particular device, you could add firewall rules on the router to force all DNS traffic to use the router's DNS forwarder.

  If using encrypted DNS and HTTPS (only), am I protected from snooping,
  including by my ISP?

Assuming you are only using those protocols, the ISP can still see the IP addresses you are connecting to, which can sometimes be enough to determine the website. Also, the TLS SNI header (unless using the encrypted SNI extension to TLS) can reveal the hostname of the website in plaintext (e.g. example.com).

  Is it bad to use encrypted DNS with Tor as mentioned
  here: https://www.privacytools.io/providers/vpn/#info ("However you
  shouldn't use encrypted DNS with Tor.")?

The link you provided already contains some reasoning behind this, although most users are just using the Tor Browser and DNS isn't even used on the user's end (the Tor network will make DNS requests on your behalf when you make connection requests to Tor's proxy). So this would only matter in certain circumstances; I would say that page is slightly misleading.


How revocation status of delegated OCSP responder is verified at the client side?

OCSP signing certificates are not normally revoked.  Clients are made aware of this requirement using the non-critical id-pkix-ocsp-nocheck extension.  To reduce the effect of a compromise of these certificates they are normally issued with a short lifetime.
However, this isn't the only option.  OCSP signing certificates could be revocable and checks could be carried out using a CRL or any method described in RFC 5280's Authority Information Access. Note that this only defines OCSP as an option, in which case it would need to be a different OCSP responder to be meaningful.
Details are in RFC 6960 Section 4.2.2.2.1.


Using a minimal set of certificate authoraties

Short answer: No.
I think you won't be happy with only three CAs. Lots of clicking around certificate warnings. This will not make your browsing safer.

Also reconsider what you are trying to achieve. I'm assuming, that you want to protect yourself from rogue and/or exploited CAs. So that means CAs that will issue certificates for google.com, etc, when Google never asked them to do that. And those certificates could then be used to eavesdrop on google.com visitors.

So, yeah, if you exclude obscure Dutch/Turkish (re. DigitNotar hack, re. Turktrust hack) CAs from your trust store, then you won't be affected if that CA is hacked. -- As has in fact happened in the past.

What you won't be protected from, is if a Sub-CA, subsidiary or reseller of your trusted CAs is hacked. This has also happened in the past. (Comodo Brazil for example.)

So what will help now?
What will however protect you, is if you use a browser, that supports certificate pinning.
Like Google Chrome for example. They have built in "Pin-Sets" for certain sites. (Google, Facebook, Twitter, etc.)

They will not a allow a certificate issued by other than a few trusted CAs to be accepted.

What workarounds exist, but are too bothersome?
What I tried for a while is the "Certificate Patrol" Firefox extension. (Last updated in 2011.)
It alarms you, when you see new certificates for a site. And then asks you to answer yes or no.

I found it too noisy to be useful for me.

There is a nice write up in chapter 5 of this PDF here:
2013-12-03, Mariana Isabel Oliveira Taveira & Thiago Sobral Marques da Silva,  SSL Certificates and HTTPS -- Issues in the current Web Trust Model for Digital Certification

What might help in the future?
What might also help in the future is "Certificate Transparency". Where the concept is that even though fraudulent certificates may be generated, at least there will be an audit trail.

And that certificates without audit trails are rejected right away. The idea being that when a CA hack is discovered:

(a) the cleanup can be done much easier. All issued certificates are in the audit trail and can be revoked in bulk.
(b) this may make it easier to discover a CA hack in the first place. As all audit trails are public.

CT is in the process of being phased in -- again leading the effort is Google Chrome -- but it is not being enforced anywhere yet.

That being said, if you really want to go ahead and create a 3-CA-trust-store then read on below.

Three largest CAs: Comodo, Symantec, GoDaddy
This article says the three largest surveyed (what ever that means) are Comodo, Symantec and GoDaddy.

W³Techs.com, Usage of SSL certificate authorities for websites (Archived here.)

So you could try to make your minimal CA set with those three CAs.


You probably were hacked because you were an easy target. And even if there are no important data at your site it can be valuable to point people to a seemingly innocent and trusted host and get them infected by drive-by-downloads etc. In your case it looks more like your host was used for SEO optimizations, by linking typical phrases to external hosts and thus increase the search engine ranking of these hosts.


RBAC and assertions, which authorization flow is better?

You're suffering from the lack of richness in RBAC. What you really want to consider is attribute-based access control. For instance in this case, you could define rules such as:

a user can post in a room he/she is assigned to
a user with the role moderator can edit messages in a room he/she is a moderator in
a user can edit their own messages...

All these are examples of attribute-based policies / rules.

NIST has had an ongoing project on attribute-based access control. You can read more on this model here.

You can also check this YouTube video for the basics of attribute-based access control.

To implement ABAC, have a look at XACML, the eXtensible Access Control Markup Language defined by OASIS.


Would a public DNS help secure downloads over an unsecure connection?

This is a very broad question about the security of downloaded files.
So, where do you download from? In the simplest form, you download a file from a URL. The hostname will be translated to an IP address. There are a number of measures to make sure that you connect to the right host:

use Google DNS (weak, but less easy to fake than a local DNS)
use DNSSEC
use hard IP addresses instead of hostnames
etc.

HTTPS does two things:

it authenticates the connection
it encrypts the connection

So yes, using https helps.
Whether checksum or hashes help depends a lot on what you use. A simple MD5 hash is sufficient to determine whether a file transfer has been correctly, but offers little resistance to a malicious attacker. If you need to be absolutely sure, use SHA-2 and have the file signed.
Another way would be to use an encrypted VPN, either directly to the file provider or to a trusted location from where a less dodgy Internet connection is available.
If it is publicly available (f.e. Linux packages), you may consider downloading them from multiple sources and comparing the results.
And the final recommendation is, if your Internet connection is not to be trusted, don't use it for such critical files; invest some time and money in a more trustworthy connection.


If all you are wanting to do is add an exe (or any file) to a pdf (or any file) then you can simply add your file to what is called 'slack space'. There are tools out there that do this and add many features but you can also do this by hand using a hex editor (like HxD).

To do this by hand:

open a hex editor.
open your pdf in the editor.
open the exe in the editor (in another window).
copy the exe hex values into the pdf hex values (after pdf file end).
save your new 'pdf', it will still open and operate as a pdf but your exe file will be there as well and you (or anyone) can extract the exe.

also, you may be interested in embedding javascript in a pdf. This alone is nothing new, but this can be used maliciously...


Is it legal to post card data from an ecommerce checkout to a PCI compliant 'store'

Yes, PCI allows you to store a customer's card provided you do so in compliance with the PCI DSS.  Specifically, Requirement 3: Protect stored cardholder data outlines what you may (card number) and may not (CVV, mag stripe) store and describes acceptable methods of protecting the data (§3.4).

In essence, you'll need to properly encrypt card numbers, and have acceptable key management processes for your encryption keys.  Alternately, your Card Processor likely supports tokenization, where they keep (and protect) the card and you keep a token that allows you to charge against that card.  This offloads the chore of protecting the cards from you to your processor.

You can get the most recent version of PCI DSS from the PCI SSC Document Library.


DHCPig not making the hosts discard IP configuration

You did misunderstand the attack. The faked packages aren't send to the client. They are sent to the server with the address of the client you want to dos as the sender. The goal of this attack is to make the server believe that the address is available again. This will only work if you prevent the real client from communicating with that server.

You can find a documentation of how this is best done here.

// When a Host obtains a DHCP lease there come some limits with it. The lease has a lifetime after which it expires if it isn't extended. But there is also an additional time limit which is called renewal time which is the time limit after which the client should talk to the DHCP server again to extend the lease. Many operattion systems even renew their lease more often than imlied by the renewal time.

When you now start portstealing your target and send a RELEASE Packet to the DHCP server the server will mark the lease as available again. You then start aquireing this lease with a fake mac address using DHCPig. When the targeted client then talks to the DHCP Server to renew his lease the server will send a NACK packet which will prevent the lease from beeing extended at least and might cause the client to discard his configuration.


How can I identify a machine with two network interfaces as one?

There are lots of interesting techniques that others are covering in their answers. Many of these are also discussed in Michal Zalewski's book Silence on the Wire. But the easiest method with Nmap is to use the duplicates NSE script. This uses various methods such as SSL certificates, SSH host keys, and MAC addresses to identify addresses that could be on the same system. It's not foolproof, but nothing really is. New techniques may be added in the future as well. Note that this only works if both addresses are scanned in a single Nmap scan.


EternalBlue requires network connectivity to SMB on the target, so if the Windows Firewall (or any firewall between attacker and target) is blocking that access, the attack will fail.

Ransomware like Wannacry depended on the fact that most organizations do not run host firewalls like Windows Firewall on their systems.


Disabling RC4 HMAC encryption in Windows Active Directory prevents current Kerberos attacks?

You would have to ban RC4 entirely to be protected. This is possible and it would prevent an attacker from requesting a TGT with an RC4 request. This is a global setting you apply to DCs. One thing to note is that most users do end up using AES eventually (unless it's explicitly disabled) as Windows/Active Directory will optimistically enable it as it determines that users can support it.

RC4 is weak for a number of reasons, but it's a weakness of the crypto system and not just the algorithm.

RC4 is just horribly broken
RC4 key derivation has no salt, so it's relatively trivial to brute force
The integrity protection is an MD5-based HMAC

AES is preferred because it uses salts during key derivation, and uses a stronger integrity protection algorithm (SHA1 HMAC).


Configure the ModSecurity box as a reverse proxy, terminate the HTTPS connections on this box and then ModSecurity will be able to inspect. Once the traffic is inspected, you can forward it to the appropriate back-end server. You can follow the guide Setting up a reverse proxy server. The site has some excellent other ModSecurity resources as well written by Christian Folini who is the ModSecurity developer and current lead.


Understanding blacklisted ciphers for HTTP2

As the rfc4880 appendix you linked to says

  Note: This list was assembled from the set of registered TLS
  cipher suites at the time of writing.  This list includes those
  cipher suites that do not offer an ephemeral key exchange and
  those that are based on the TLS null, stream, or block cipher type
  (as defined in Section 6.2.3 of [TLS12]).  Additional cipher
  suites with these properties could be defined; these would not be
  explicitly prohibited.

Stream suites are blacklisted because the only stream cipher used in TLS is RC4 and attacks against RC4 have practically exploded in the last few years; see rfc 7465.

CBC suites are blacklisted because it is now recognized TLS-nee-SSL use of MAC-then-encrypt was a poor choice (although before the first clear recognition of this, Bellare & Namprempre in Asiacrypt 2000) partly because MTE combined with CBC (which requires padding) in an online protocol allows padding-oracle attacks like POODLE and Lucky13. POODLE severely breaks SSL3, but SSL3 was officially obsolete already and POODLE finally motivated people to eliminate it. Lucky13 requires precise timing and is not very practical now, but it shows an approach that might well improve. (SSL and TLS1.0 use of exposed IV for CBC also allowed BEAST, but that part is fixed in 1.1 and 1.2.)

Null ciphers are blacklisted because, well, their undesirability should be obvious.

This leaves only AEAD suites, and in practice only GCM, at least for now. Note that AEAD requires TLS1.2, which is not yet universally implemented, so generic tests like SSLLabs still accept CBC modes to allow for servers and/or clients using 1.1 and 1.0 (but not SSL3 as above). Chrome used to describe anything other than 1.2 with AEAD and ephemeral key exchange as 'obsolete cryptography', and security.SX has quite a few Qs about that, but on retest (51.0.2704.84) it seems to have stopped. HTTP/2, which comes along after TLS1.2 and AEAD 'should' already be in place, can reasonably be more demanding.

Unless we get practical quantum computers -- a very big unless people are now worried about -- the difference in strength between AES-128 and AES-256 is meaningless. It's the difference between 'unbreakable in our galaxy, but might be broken by someone controlling the entire universe for zillions of years' and 'unbreakable even in the entire universe'. No matter how perverse your collection of cat videos, you shouldn't care if it's decrypted after you're long dead, all your descendants are dead, all human beings are dead, and our planet and solar system no longer exist.

(Although given all the other media features added in HTTP/2, I'm disappointed they didn't add any capability to prohibit or at least seriously limit and degrade cat videos. Well, there's always X-.)


Implications of Intel's SGX extension for malware detection and white hat reverse engineering

It is very unlikely that malware authors will be able to SGX. In fact it is very unlikely that most people will be able to use SGX. This is because Intel has implemented strong cryptographic DRM on SGX.

In order to be able to launch an SGX program, it either needs to be signed directly by Intel, or by another local SGX program that is signed by Intel. Intel has not been forthcoming with details about SGX, but it is clear that only “licensed” developers will be able to use it. “To be fully utilized, Intel SGX [requires] additional software capabilities, which will begin to be delivered by the ecosystem later this year.”† “The SGX software stack [...] is being made available on a licensed basis.”‡ “The SDK is not publicly available.”* You can find more information about how the DRM is implemented at https://jbeekman.nl/blog/2015/10/intel-has-full-control-over-sgx/

To answer your narrower question: SGX programs are not encrypted before launch, so it is possible to analyze the code as you would any other binary. However, it is possible for that program to be a small bootstrap program (stage 1) that talks to an external server over the Internet. The external server could send the important code (stage 2) to the stage 1 program after it has verified that the stage 1 program is launched securely. In this case, you won't be able to analyze the stage 2 program.

Also note that--since SGX programs can't make syscalls--in order for Malware to do anything to your system, there needs to be a insecure wrapper program to actually talk to the system. You will be able to analyze this wrapper program using standard techniques.

† http://download.intel.com/newsroom/kits/core/6thgen/pdfs/6th_Gen_Intel_Core-Intel_Xeon_Factsheet.pdf
‡ https://software.intel.com/en-us/forums/intel-isa-extensions/topic/583931
* https://software.intel.com/en-us/forums/intel-trusted-execution-technology-intel-txt/topic/600736


The secret of credit card transaction security is that by law (in many jurisdictions) the card issuer is responsible for fraudulent transactions after a certain limit, not the card holder. Since they already assume the bulk of the liability, most (all?) simply make the jump to say that the card holder is not responsible under any circumstances for fraud.

This means that card security is simply a cost-benefit trade-off for the issuer. It's worth the cost for the issuer of writing off a certain amount of fraud if in exchange they get a reasonable return for the policy. Hence the $100 limit; Visa is confident that within that range, they can detect fraud reliably enough to make it worth their while to remove certain security measures.

Therefore, whether or not it's secure is their problem, not yours. Obviously you have to actually report suspicious transactions. This makes it a bad idea to keep an account open that you don't monitor. But that has always been the case.

This is really the way it should be. If the party liable for security is the one in the best position to implement it, then the level of security you get tends to be appropriate for the value of the thing that's being secured.


VP of IT claims he unhashed 100% of all 16k employees' PWs. Is he lying to us?

The only realistic way that 100% of passwords got cracked is if you're storing LM hashes on windows.  LM hashes split into 2 seven character chunks making brute force/rainbow table attacks practicable (they're also case insensitive for added ease). Rainbow tables exist for this and it's easily do-able.

Outwith that, anyone with 10+ character passwords that aren't in a dictionary (or findable by mutating dictionary words) aren't going to get cracked on any reasonable system, even with weak algorithms (e.g. md5) and no salt.  AFAIK rainbow tables aren't practical on passwords that long (for reference free rainbow tables have a 2.8 TB pack of MD5 hashes which tops out at some nine character passwords (not full char set).

One point I would make is that if I was the VP of IT I'd be concentrating on getting rid of LM hashes rather than just telling people about good password practices for the very reason that he was able to retrieve 100% of passwords :)


You could start by reading the full description of CVE: 2012-0809 and then look for a poc. A brief introduction to format string exploitation is a good starting point.


How do I minimize the number of passwords leaked when a PC gets compromized?

This is exactly the threat that standards such as FIDO and WebAuthn aim to mitigate.  These standards use public key authentication to authenticate with web sites and other services, using a private key that is stored on a device (such as YubiKey).
The private key never leaves the device, so even if the computer is compromised, the attacker is not able to access the private key.
Adoption has been gradual, but a fair number of sites support these standards now.  Some of them are listed at https://www.yubico.com/about/reference-customers/.


Putty settings - Protocols and Algorithms to warn about

In SSH, for all algorithm classes (encryption, MAC, key exchange and public-key authentication), the client and the server send to each other their lists of supported algorithms; the client lists are ordered by preference, and that preference is honoured: the protocol is such defined that the chosen algorithms will be the first in each client list that also appears in the corresponding server list.

I recall that point because it highlights what this "warn below here" option really means. It means that there are some algorithms that the human user would really prefer not to use -- but, for some reason, he included them in its list of supported algorithms. So what will the human user actually do if he gets the warning ? Will he click on "OK, I got it" and proceed with the connection ? Or will he bail out ? In the first case, the algorithms are thus functionally supported, while in the second they are not. Does it really make sense to have a warning popup under these conditions ? If the user does nothing else about the warning than deciding whether to keep connecting or abort, then the warning is meaningless; it would be simpler and safer to simply omit from the list all algorithms that the user is not ready to use.

The warning is useful when the user (on the client side) can, at some point, alter the configuration of the server. It can then serve as a indicator for a misconfigured server, that the user may then fix himself at a later point.

All of that being said, there are reasons why some algorithms are preferable to others. In no particular order:

Protocol version should be SSH2 only. SSH1 has flaws, and if the server you are trying to talk to supports only SSH1 then it is very old software which is probably riddled with unfixed but known vulnerabilities, so you do not really want to connect to that server at all.
DES uses a 56-bit key (officially 64 bits, but 8 bits are ignored in the process, so effectively 56 bits). This is in range of exhaustive search by attackers with a bit of budget (in the thousands of dollars, not in the millions) so you really want to avoid that.
RC4 has known biases. SSH can support some variants that discard the first 1536 bytes of RC4 output, which removes the biggest biases, but not all. While there not has been any published practical exploitation of RC4 biases in the context of SSH yet, this is still a worry and it is recommended not to use RC4.
Blowfish and 3DES are 64-bit block ciphers. In SSH, they are used in CBC mode, which means that they begin to run into trouble after encrypting about 232 blocks (of 8 bytes each), i.e. about 32 gigabytes. If you occasionally transfer gigabytes of data over a single connection, then you will want to avoid 64-bit block ciphers, and concentrate on 128-bit block ciphers like AES.
3DES is slow in software. This may matter if you have a fast network (gigabit ethernet) or very slow hardware (not a PC).
If you have the choice, prefer "modern" encryption modes like GCM or CTR instead of CBC. The mode describes how the block cipher will be used.
For key exchange, you may want to avoid the "group 1" which uses a 1024-bit modulus. Breaking Diffie-Hellman modulo a 1024-bit prime has never been done in a public demonstration (current record is a 596-bit modulus) but it is within technological reach of mankind (projected budget would then be in the dozens or hundreds of millions of dollars). The "group 14" is a 2048-bit modulus, which is fine.
"Diffie-Hellman group exchange" is DH in server-chosen parameters, and normal servers will take care to select parameters that at least match the strength of their authentication public key. So this is safe as long as the server (or its administrator) does not do anything stupid.
RSA key exchange is pretty rare, because it involves generating an ephemeral RSA key pair on the server side, which is relatively expensive. Usual servers do not do that.

So my advice would be: remove all symmetric ciphers that are not AES; keep only DH group 14 and the "DH group exchange"; don't bother with the "warn me" limit; instead, use the failure to connect as a warning. If you cannot connect to a given server with sane parameters, then something is amiss and you should pause and think -- a forced abort is more likely to make you think than a simple warning popup. Maybe the lack of AES support for a given server is normal, but this requires an explicit decision, not a popup that is to easy to ignore.


USB to Firewire converter is a security issue?

The security issues with FireWire come from Direct Memory Access: the FireWire hardware can read RAM contents directly, and (that's the critical part), the FireWire device gets to tell what parts of the RAM should be read and when. Of course, under normal operations, a FireWire device will not read RAM unless the machine tells it to do it; but a malicious FireWire device could read all RAM contents on its own initiative, without being ordered to do so by the OS. Indeed, the OS kernel would not even be aware of this mass slurping of memory. Implementations exist with another computer as "the malicious FireWire device".

This property of FireWire is convenient for very low-level hardware debugging, but it is somewhat scary with regards to security.

This contrasts with USB, where DMA can occur, but only when initiated by the host system explicitly. The device receives an order which amounts to "yay, now you can read a lot of data, I've setup DMA just right" but has no way to trigger the DMA transfer and/or to select the relevant addresses in RAM.

Now for a FireWire-to-USB converter, things become speculative because it depends on how the converter is implemented. However, it can be envisioned that when the FireWire device asks for some DMA, the converter sends the request the the machine over USB, and the corresponding driver sets up the DMA transfer on behalf of the device. So the same security issues should be present, unless the OS (through the converter driver) enforces a security model in which such DMA transfers are first validated before being authorized. At least, things go up to the CPU level, so the OS has theoretically a chance to intervene. I doubt that most converter drivers would do that, though.

For FireWire-to-PCMCIA, the DMA might occur directly (without going through the host CPU at all) because PCMCIA is just a hotplug version of PCI, and PCI has full DMA access. The conversion may occur directly in the converter without hitting the host-side driver at all. Caution dictates that you should assume that a FireWire-to-PCMCIA converter exposes to the same vulnerabilities as raw FireWire.

The really scary part is that in some operating systems, simply plugging the converter may trigger an automatic download of the relevant driver, even if the host system is "locked" (e.g. no logged-on user at all).


What security features and qualifications should we look for in an online backup provider?

I'd say that the PCI compliance aspect is going to complicate things more than a little bit and that you should really speak to your QSA about requirements.  Whilst I'm not a QSA it would seem to me that if you backup card data then that backup service would effectively become part of your cardholder data environment.

Apart from that one thing I always look at for online backup facilities is whether your data is encrypted when stored with them.

Unfortunately it's not as simple as it either being encrypted or not, as all providers will say that it is.  some providers use a common key for encryption which means that they can get access to the data without your password, which means that if their security is compromised it could lead to your data being compromised

So one important thing to consider is whether your data is encrypted in such a way that compromise of their systems won't compromise your data.

A service I've used for backups is SpiderOak and their model is to handle encryption client-side so that the encryption key shouldn't be available on their server.  The downside here is that if you forget the password there's no way for them to retrieve the data.

The question about the service being able to restore data to your servers would seem to be a security concern as to achieve that it would seem that the provider would need persistent write access to your server.


This is a common trick to speed up encryption and verification. The exponent is special, in that, it is a small prime number with only two bits set, which makes modular exponentiation in software fast enough. Another commonly used public exponent is 3, but I think that one is falling out of favour these days.

See this question for some more information on the security of these special exponents.

As for the "how" of these exponents, since the modulus is a randomly generated (within some constraints, of course), the private key is still random, and cannot be determined from the public exponent and modulus alone.

The reason why we want as few bits in the exponent as possible is the way modular exponentiation is done. When you are calculating the modular exponentiation using the public key, you only have two numbers: the public exponent, e, and the modulus, n. For private keys, we can can have some more information (actually the prime factors of n) to speed up calculations (you can look up "Chinese remainder Theorem" for RSA if you are interested), but obviously these prime factors cannot be distributed along with the public key. So, we are left with the standard square and multiply algorithm.

The main idea of the algorithm is to square the message for each bit of your exponent, and multiply it to an accumulator when the corresponding bit in the exponent is set. Say, you want to calculate m13. You first write it as a multiplication of a series of m2j, i.e. m23·m22·m20. Set a variable to m, and result to 1. Now, start counting from 0 to 3 (the maximum bit length of modulus). For each value, if 13 has the bit position at counter set, multiply your result with the variable. Before increasing your counter, square your variable. With this scheme, you'll calculate m, m2, m4 and m8 at each iteration of your loop from squaring your variable. When a bit is set in exponent, you pick the value, and multiply it with your result to get m·m2·m8 (which is m13). For a random 1024 bit key, you'll need to call sqrmod(m, n) 1024 times, and also mulmod(accumulator, m, n) roughly 512 times (the bits are random, so we only know it is less than 1024, and 512 on average).

When you have a small exponent with only two bits set, say 65537, you need to square only 16 times, and multiply only once (m2k can be calculated by initializing a value to m, and repeatedly squaring it k times, and m65537 = m216·m). It is even faster when exponent is 3: you square once, and multiply once.


Limiting Concurrent Login For System Admins On Windows Domain

so I don't think this is going to be 100% possible.

What you can do is limit your servers to a single RDP session :
https://support.managed.com/kb/a1816/how-to-enable-disable-multiple-rdp-sessions-in-windows-2012.aspx

What you won't be able to prevent (I don't think) is someone using a console session at the same time (so MSTSC /admin) and the equivelent physical access console session.


Google Chrome stores recent items I've opened in my computer?

It is certainly normal for Chrome to do this. It is part of the Omnibox functionality, helping google provide you with the results you want.

To get rid of the history provider cache, simply delete that file.

You could have a read of this question on SU discussing editing it.


Why do we use such a redundant language (English) for network communication?

We don't use English for "network communication," we use network protocols. The things people say in natural language are usually much less interesting than the things computers say to each other.

LFA depends on the definition of a "letter." In English and ASCII (or more likely UTF-8) encoding, this corresponds to one byte. To do this kind of analysis, then, you need a single-byte cipher like XOR or a Caesar cipher. You can do similar things with a Vigenère cipher, with a little more work. These are not in common use, though: we usually use block ciphers or stream ciphers.

Block ciphers in Electronic Code Book (ECB) mode are subject to block frequency analysis, which is not as foolproof, but still is a valid attack. At larger scales, this is what is behind the "seeing the penguin" demo.

If any of this is interesting to you, I highly recommend you try Matasano's Crypto Challenges, which will take you through practical implementation of real crypto attacks, from frequency analysis on XOR ciphers to padding oracle and repeated-nonce attacks.


Understanding differences between kernel-based TCB and micro-kernel TCB

Code running in the kernel mode always have full permissions to do anything, including to crash the kernel or to corrupt its internal data structure. User mode drivers restricts those capabilities so that communication with the micro kernel are forced to be done over well specified interface. For example, if a storage device driver had a bug such that a pointer it uses as destination for a copy buffer sometimes is used uninitialized, in macrokernel, there's a chance that the uninitialized pointer can point to the kernel's own memory, and the driver might overwrite the kernel's data structure, like the process table, likely leading to a total system crash (kernel panic). In a microkernel, since the driver can't write directly to the kernel memory, such errors would at most just crash the device driver itself, and the kernel can restart the device driver process.

In general, the thinking is that microkernel have a better security architecture than a macrokernel, however it comes at a performance penalty. Modern micro- and macrokernels employs a number of tricks to minimize their weaknesses.


If you know for sure that no user will ever be logged in, you can't really do that much with a reflected XSS vulnerability (you can't steal cookies, you can't post requests on their behalf, you can't perform phishing attacks, etc).

I would still consider this a possibility to deface their website though. Sure, it's reflected, but if you post a specific link somewhere, and someone visits it, their website will show content you control, which obviously should not happen (and which is pretty much the definition of defacement).

If there may be a reason that the other team does log in (for example, the requirements may change, and the contest may require them to log in), no one will click a malicious link doesn't necessarily need to be an obstacle. You don't need to send the other team a link to their website, you just need them to visit a website where you can place JavaScript code. It does require a bit of social engineering, and may be difficult (as they are expecting attacks), but it doesn't necessarily have to be impossible.


The Ubertooth one will allow you to sniff bluetooth traffic.  It is fully capable of being placed into monitor mode and can be used with tools such as Kismet to perform bluetooth sniffing.  There may be additional functionality that will allow you to perform packet injection as well.  However if the traffic is encrypted this may not allow you to see the packets in the clear but it may give you a good start at reverse engineering the communication protocols.