Flash Objects SWF security (ExternalInterface.call)

The ExternalInferface.call() is designed for invoking javascript, so this function as written effectively gives you the opportunity to invoke arbitrary javascript in the execution context of the website, which is already a serious security hole.

http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00001039.html

How specifically to exploit it?  There's a ton of web sites about javascript security holes, you just have to insert one and invoke it in the execution context of the web site.


How to secure and limit access to a web based application hosted on a local server

Keeping the database online actually increases your attack surface, but if you plan to use a hosting company that creates and secures this for you, it might be helpful.  As far as security for this, you would want to make sure all connections to the database use ssl.  This prevents plain text passwords from being sniffed.  You would also want to make the password complex enough to prevent brute forcing.  As far as limiting the ip address that can connect, this does help, but keep in mind most attacks attempt to originate from queries passed through sql injection.  Your application seems to be web based, so if an attacker was able access a page that queried the database, the ip address wouldn't stop the attempted injection.  Not to discourage however.  Ip whitelisting, deny everyone else, would be a good step, but you will want to monitor/access the application using the database for any vulnerabilities.


Mixed content - stylesheet being blocked because of a querystring parameter?

It's a server configuration issue.  No, I don't know why your server is configured to do this, since it's generally a bad idea.

Using my general-purpose HTTP diagnostic tool, wget, to retrieve https://www.w1office.com/CSS/all.min.css, I get:

Connecting to www.w1office.com|91.151.215.29|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 41241 (40K) [text/css]

On the other hand, when I retrieve https://www.w1office.com/CSS/all.min.css?v=2, the result is:

Connecting to www.w1office.com|91.151.215.29|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://www.w1office.com/CSS/all.min.css?v=2

When the query string is used, your server responds with a HTTP redirect to an insecure address.


The difficulty of securely storing a password

If you're not worried about malicious insiders, here's what I'd do:
Issue each authorized user a flashdrive with a file on it. The file contains the "password" (ideally it should be too long and random to easily memorize or type, so not really a password in the usual sense). The drive is encrypted using a full-volume encryption method (BitLocker, VeraCrypt, etc.) and each authorized user has their own passphrase to decrypt their flashdrive. The software reads the LDAP "password" out of the file, once the flashdrive is installed and unlocked.
Advantages of this system:

The LDAP admin password can be completely beyond human ability to memorize.
The password copies are stored on physical objects that are easy to maintain an inventory of.
An attacker who steals a user's flashdrive hopefully won't know the passphrase to unlock it, so they can't decrypt the key.
An attacker who guesses a user's passphrase hopefully can't access their flashdrive, so they can't use the passphrase for anything.
In theory, each user could have a unique "password" for LDAP administration, allowing monitoring of usage and easy disabling of individual accounts at need.

Disadvantages:

Kind of a hassle both for the users and for the IT folks who need to create and manage all these flashdrives.
Changing / rotating the LDAP admin password is a mess, especially if everybody shares the same one; all the drives need to be updated.
More common for people to get locked out because they lose a small object or forget a passphrase than if they only needed to keep track of one of those things.
A malicious insider can just unlock their flashdrive and then copy the file contents out of it, trivially (or probably just decrypt the flashdrive).

You could also use hardware tokens, but most of the advantage over an encrypted flashdrive there is the ability to make the secret non-exportable. Unfortunately, that would prevent having the secret be a password, which must be transmitted in some form. That puts a real damper on how hard you can hide it, and in particular makes it totally impossible to hide from an insider.

IF at all possible, don't use a password here
Establish the connection using some form of public key cryptography. Mutual TLS, SSH with public key, whatever. Use a system where there's an unpredictable string to be signed or decrypted, and proving that you have the private key is used for authorization. Then use a hardware security module (HSM) to store the private key, and make sure it's not exportable. The key can now never be extracted, so the only way to use it is if you also have access to the HSM. Depending on your needs, this could be an HSM that is given to every authorized user or that is only available by checking out one of a limited number (possibly only 1) from a trusted source, and it could be relatively tied to computer hardware (such as the TPM in a PC) or portable (such as a Yubikey).
For extra security, you might protect access to the private key with a passphrase or other secret, turning it into effectively a two-factor authentication requirement (the attacker needs both to have the HSM, and to know the string that unlocks access to its key). SSH and GPG private keys already typically are encrypted using password-derived keys, but there are better systems than those use.

You can't do anything about an attacker with root access to a machine where the software runs. If the software can communicate with the LDAP server, the attacker can tap that communication, edit it to serve their own purposes, initiate it on demand, etc. Even if there's no post-authentication session token to steal, and the authentication sent on every request is done without exposing the secret (e.g. instead of a password, you use a symmetric key to HMAC the message or a private key to sign the message, and the key is stored somewhere the attacker can't read like inside an HSM), for as long as the attacker has access to the compromised system they'll have full control over its communication with the server, and you can do a LOT of damage in a short time.


This is a bug in Nmap. Thanks for discovering it! Short answer: there was a bug in how we counted how many addresses were already scanned, which I just fixed in r36341.

Longer answer: Nmap runs scans in several phases. The important ones for this bug are host discovery (Ping scanning) and port scanning. Nmap loops over all possible addresses, doing host discovery in large chunks when necessary, and grabbing some number of "up" hosts to do port scanning on in a group. It stops looping over addresses when it has enough targets for a hostgroup or when the addresses run out. For -iR, the addresses never run out, so instead we check whether o.numhosts_scanned is less than o.max_ips_to_scan. That would work except that we don't consider an "up" host "scanned" until after the port scan phase. So there's the potential to check extra addresses. Over a long scan, most of these get counted anyway because they increment o.numhosts_scanned after the port scan phase and before the host discovery phase for the next group, but the last hostgroup will have some carry-over. I fixed this by adding an extra loop check to ensure that "up" hosts were added to o.numhosts_scanned before checking against o.max_ips_to_scan during the discovery phase.

Example debug output from nmap -iR 2 -p80 -d -n:

Initiating Ping Scan at 15:14
Scanning 2 hosts [2 ports/host]
Completed Ping Scan at 15:14, 1.48s elapsed (2 total hosts)
Overall sending rates: 4.06 packets / s.

This shows that we correctly ping-checked 2 addresses.

Nmap scan report for 20.240.133.236 [host down, received no-response]

One of them was down, so the report is printed immediately. One of them must have been up because we only got one such report.

Initiating Ping Scan at 15:14
Scanning 54.28.85.198 [2 ports]
Completed Ping Scan at 15:14, 1.48s elapsed (1 total hosts)
Overall sending rates: 2.71 packets / s.

Oops! The one "up" target wasn't counted towards the number of scanned hosts, so ping scan thinks it needs to scan one more to be done.

Nmap scan report for 54.28.85.198 [host down, received no-response]

That one was down. So 2 down hosts and one up.

Initiating Connect Scan at 15:14
Scanning 187.142.197.40 [1 port]
Completed Connect Scan at 15:14, 0.06s elapsed (1 total ports)
Overall sending rates: 17.06 packets / s.
Nmap scan report for 187.142.197.40
Host is up, received conn-refused (0.059s latency).
Scanned at 2016-09-29 15:14:26 UTC for 3s
PORT   STATE  SERVICE REASON
80/tcp closed http    conn-refused
Final times for host: srtt: 59196 rttvar: 33779  to: 194312

And here's the third one: port 80 was closed.

Read from /usr/bin/../share/nmap: nmap-payloads nmap-services.
Nmap done: 3 IP addresses (1 host up) scanned in 3.06 seconds

And here's the output showing that 3 IP addresses were scanned, even though I requested only 2.


Can a fingerprint be reconstructed from a device that uses it for authentication?

Devices that support biometric authentication are equipped with Trusted Execution Environment (TEE) that stores fingerprint data in its own isolated tamper-resistant storage. The biometric sensor communicates with sensor driver which lives inside TEE. When a user wants to enroll fingerprint, fingerprint data from the sensor goes directly to the sensor driver where it is stored by TEE.

At the time of biometric authentication, TEE only answers whether the fingerprint was correct or incorrect. Raw fingerprint data is never accessible from outside the sensor driver. Hardware access is limited to the TEE and protected by an SELinux policy. The Serial Peripheral Interface (SPI) channel is accessible only to the TEE.
TEE does not hash fingerprint data because every time you put your finger differently on the sensor. The mathematical values can be used to reconstruct your fingerprint if algorithm is known.TEE encrypts fingerprint data with a symmetric key. It also signs biometric metadata that is outside of TEE and is used by TEE in validating fingerprint. So if you try to swap TEE chip with your own device's TEE, signature check will fail along with user authentication.
Even if you obtain root access on the device, fingerprints that are already stored in TEE can never be extracted. Patching sensor driver to leak fingerprint data will fail signature check of TEE image on boot and the device will brick. TEE image is still verified even if the bootloader is in unlocked and unlocked_crirical state. Emulating TEE on rooted device is still not enough to hijack sensor communication as SPI channel is bound to the real TEE.
Theoretically, you can compromise SPI channel with hardware debuggers on unrooted device to leak future accesses to the sensor but this attack is not scalable. In order to test sensor driver, some OEMs intentionally leak sensor data to testing application in prototype devices. It seems Mi forgot to disable the access for some of its production devices which is a security hole because any application can access sensor data on those devices. How this is not already violating SELinux policy is unclear.
The easiest way to reconstruct fingerprint is to copy prints from the surface. Fingerprint protection is as secure as physical protection.

Fingerprint HIDL
How does Android save your fingerprints?


Does giving out Dell service tag of my device pose a security risk?

No, giving out your Dell service tag isn't a risk as such - all it can really be used for is logging support calls with Dell when you need help due to a fault with your machine. And if it resulted in them needing to send an engineer they'd ask for the address to go to fix the device. I guess if someone really wanted to they could log a load of support calls for your machine but it wouldn't impact you in any way, Dell might just get a little annoyed.

Regardless of that, the service tag is pretty public information for example if you're using a laptop all someone has to really do is get a glance at the bottom.

To add to this I believe if you create an account with Dell you can bind devices (Via their service tag) to your account that way if someone did give them your service tag they would ask that they prove their identity (In theory) - this doesn't stop someone from making an account and doing it, it's just unlikely as it won't benefit them to do this.

I wouldn't be worried about someone having the service tag - it is not a threat.


After exploiting a router using routersploit, what do you have control of?

Firstly, a router is a computer, so like any other computer, you get the ability to use its resources for your own purposes: processing power for cryptomining, use of its networking resources for DDoS attacks or spamming.
Secondly, a router sits across the network path of any computers on its network, so it provides the ability to man in the middle attack all network traffic from those computers. This allows you to attempt to steal data for identify theft and other forms of financial fraud.
Thirdly, in more targeted attacks, a router can serve as a jumping off point within the network of the target, allowing attacks onto other systems that may bypass firewalls due to the traffics origin from within the network. If the router appliance is also the firewall, exploiting the router may allow the attacker to completely ignore the firewall.


The Requirements of a Cryptographic Algorithm

What you are referring to is Kerchoff's Principle. Beside that a couple of formalizations of security criteria (along with very simplified explanations) are:

Ciphers

Indistinguishability under chosen-plaintext attack (IND-CPA)
Indistinguishability under [adaptive] chosen ciphertext attack (IND-CCA1 & IND-CCA2)

These roughly say that ciphertexts should not leak information about the plaintext, and that plaintexts should not allow an adversary to infer anything about their corresponding ciphertexts. Some more details here.

MACs and Digital Signatures

Strong existential forgery under chosen message attack (SUF-CMA)
Weak existential forgery under chosen message attack (WUF-CMA)

See page 11 of this paper. These roughly describe the ability of an adversary to forge a signature for a given message without having knowledge of the signing key.

Hash Functions

Collision resistance
Preimage and second-preimage resistance

These roughly say that given the output of a hash function it should computationally intractable to find the input to the function that produced that output or to find two values that produce the same output when fed through the hash function.


What remote forensic technique could be used to discover a malware running via process injection

I would definitely use Process Mon from Sys Internals as well.

Link: Process Monitor Download Page

I would also look into AutoRuns as well from the same site. If by chance the malware is persistent, AutoRuns will show you whether or not the process is initiated at boot - as well as other useful information. Good luck!


An application proxy (or more commonly called application level gateway) is a firewall at the application level. A packet filter is a firewall at the packet level. This mean with a packet filter you are not able to filter web traffic for malware since it has no understanding of the applications protocols of the web (i.e. HTTP). An application level gateway instead understand the protocol and can thus scan the body of a HTTP response for malware.

See also the OSI model: a packet filter is at layer 4 while an application level gateway is at layer 7.

  Firstly,Why is a packet filter is enough in a situation where traffic is busy?

This statement is wrong. The only criterion to decide if you use a packet filter or an application proxy should be the security requirements and not the performance. While a packet filter is much faster than an application proxy it is of no use if you actually need application level inspection.

But a packet filter has its use too as a way to separate networks or as the first line of defense like against DOS attacks.

  Secondly,Isn't application proxy safer than packet filter considering proxy can filter bad data like virus?

That is correct and very important.

  Thirdly, is it okay to use stateful packet filter instead of packet filter?

A stateful packet filter is still a packet filter so you can use it. Keeping states has the advantage that you can make more strict rules (i.e. based on connections and not on single packets). But it needs more memory.


What are the security measures taken on websites that allow online scripting such as jsfiddle and codepen?

What you need to worry about here is XSS. Scripting in general is not (supposed to be) dangerous, since the browser limits what an attacker can do anyway. At least you can not do anything on JSFiddle that you can't do on any other webpage.

But what about the XSS? If you look at the source of JSFiddle you will find this:

<iframe sandbox="allow-forms allow-scripts allow-same-origin allow-modals allow-popups" allowfullscreen="" name="result" frameborder="0">

So the area where the code is executed is contained in an iframe. The URL of that page is https://fiddle.jshell.net/_display/. Since it is in a different domain from JSFiddle itself, it can not access any of the JSFiddle cookies. So that domain is pointless to XSS, because it contains nothing of value. It is just a page that returns any scripts you POST to it.


What are the differences between "simple" UAC and two user accounts on Windows?

Short Answer
Use a limited account for performing the day to day activities and have a separate account with administrative privileges for performing tasks that require elevated privileges.
Long Answer
User Access Control is not considered a security boundary by Microsoft. The reason is that due to the design of Microsoft Vista and later, processes hold only a limited privilege token when launched and explicitly require elevated privileges which are protected by the UAC in a default state. As you can see, as long as the process don't request elevated privileges, UAC won't come into play. It means a malware will have access to everything the user account has access to without requiring any elevated privileges. The data of the user is much more important than getting NT AUTHORITY\SYSTEM privileges.
Another thing which needs clarification is the Always Notify setting of the UAC. It is generally understood that UAC in the default state i.e. "Notify only when programs try to make changes to my computer" can be bypassed in a lot of ways. Exploitation frameworks such as Metasploit has dedicated modules to achieve the UAC bypass in the default state where the process is silently elevated without any UAC consent dialogue. However, the same is true for the Always Notify setting as well. For example, take a look at technique outlined here. A brief summary of the technique is instead of asking for elevation interactively, register the process to the Task Scheduler with the logged in user. In Microsoft terminology, it is called S4U (service for user). The task when executed will have elevated privileges without requiring any consent from the user of privilege elevation and this is true even if the UAC is set to the highest security setting which is Always Notify.
Conclusion
UAC is beneficial in a lot of ways if the user don't have administrative privileges. Have a separate limited user account where every time elevated privileges are required, the user will be asked by the UAC prompt for the administrator user's password. If the user already have administrative privileges, UAC is of little use.


Eavesdropping on a specific port of machine in the WLAN from a different machine, possible? (using arpspoof)

I tried to explain in which cases WPA networks are subject to "spyability" by other users  in this answer. Short: If the attacker isn't on the same WPA2 network, you're safe. If the attacker is on the same network, you're only safe if the network uses WPA2-Enterprise, and not WPA2-PSK.

For unencrypted networks, you can obviously simply sniff off the unencrypted packets from the air – no need to ARP-spoof anything. It's simply like sitting in the middle of a conversation.

For WEP, it's the same when the attacker is in the same network. If the attacker's not in the same network, he'd have to crack the WEP encryption – but that's sadly pretty realistic, given that you can derive the key by triggern known plaintext in relatively short time. As soon as you have the key, sniffing is as easy as on an unencrypted network (or an Ethernet hub, if you remember these).

ARP spoofing is a technique to make other computers send data to you instead of their intended target – but that probably won't work in a simple Wifi – all the station will probably want to send packets to the access point, which doubles as router, and you'd have to convince that router that you are the legitimate holder of its IP address the moment you try to send forged ARP replies.

That'll simply fail, usually. In more complex networks, the access point might not be the router, but still, you'd very likely have to poison the ARP cache on the "backbone" side of the Access Point – a non-trivial problem.


Open:

The attacker sends a SYN probe to the port he wants to test
The port sends back a packet with SYN and ACK flags

Closed:

The attacker sends a SYN probe to the port he wants to test
The port sends back RST/ACK packet directly

Filtered:

The attacker sends a SYN probe to the port he wants to test
Two scenarios:

The port responds back with ICMP error messages such as type 3 code 13 (destination unreachable: communication administratively prohibited)
More frustrating scenario for the attacker: the SYN probe is dropped (no answer at all)

Unfiltered:

The attacker sends a ACK probe to the port he wants to test
The port responds with RST packet

Open/Filtered:

The attacker sends a UDP, IP, FIN, NULL or Xmas probes to the port he wants to test
No answer is received

Closed/Filtered:

The attacker performs an idle scan  (-sI)
The zombie machine receives RST packet,  or nothing at all from the target machine (this means the attacker will receive IPID=1 from the zombie)


What is the term for requiring a user to go through an additional activation/verification process on new devices only?

This falls under the area of Adaptive Authentication, although that term covers the whole package - deciding who you are based on multiple factors, and getting more reassurance using multiple resources, including pushing out cookies to act as a factor in future authentications.

A couple of well known examples are:

RSA Adaptive Authentication
OpenAM / ForgeRock

Determining if you're coming from a device that the server knows about is a "device cookie" in ForgeRock or "device identification" in RSA.  But, really, they have multiple factors that they assign weights to when deciding to trust you:

Have there been failed authentications for this account?
Is the client IP address on a whitelist?
Is the client IP address in a good geolocation?
Has the account logged in from this IP previously?
Is the device recognized from past logins (e.g., device cookie?)
How long has it been since this account last logged in?

Coming from a recognized device is weighted heavily, so if that device cookie is missing you often have to do the work to get it.  But it's quite possible to write a policy where that isn't the case, given the variety of checks you can use in determining trust.


Notice of Credit Card Fraud via text on my phone someone responded how did they do it?

Your iPhone (assuming its relatively current) can perform SMS relaying, sending/receiving messages using the iMessage app, on other devices that are logged in to your account.  You should check your associated devices via the Apple web site to ensure there are no unknown devices listed and remove them if there are.

Assuming you are not using a jailbroken iPhone your apps should be safe, but to be sure you should review all the installed apps on your phone for any that were recently installed that you don't recognize.


Crypto Ransomware - How decryption is done when user accept to cooperate?

It depends on the individual malware, but normally a random symmetric key is generated on the machine (which is used to encrypt the files), which is then encrypted with an asymmetric public key embedded within the application. This encrypted key file is kept locally on the system, but it is useless unless you have the private key to recover the symmetric key.

When the user cooperates, the encrypted key file is given to the bot owner, who can then use their private key to decrypt the symmetric key. This key file and a decryption program is then given back to the user, which then allows them to decrypt their files.

In terms of "proof" of decryption, I'd imagine the user sends the file to the attacker and they decrypt it as proof, rather than providing a single-file decryption program.


PHP SQL Injection Vulnerability In UPDATE Statements

The example you give results in the value 0 (not NULL) being returned. This is because the query you constructed ended up to be a boolean comparison. The = within the assignment part(s) of an UPDATE statement is a comparison operator, not an assignment operator as you might expect.

Injection vote`=1, `vote`=10+`vote results in query UPDATE mytable SET /*part1*/`vote`=1, /*part2*/`vote`=10+`vote` = `vote`=1, /*part3*/`vote`=10+`vote` + 1 which deconstructs to this (using == as a comparison operator for clarity:

PART1:
vote = 1

PART2:
vote = ((10+vote) == vote) == 1
vote = ( 11 == vote ) == 1
vote = ( 11 == 10 ) == 1
vote = FALSE == 1
vote = FALSE (0)

PART 3:
vote = 10 + vote + 1
vote = 10 + FALSE (0) + 1
vote = 11

The more interesting injection would be to just set the vote column and then ending the query by using a comment:

$vote = "vote` = 1337 -- and we don't care about the rest";
// results in:
// UPDATE mytable set `vote` = 1337 -- and we don't care about the rest` = `vote` = 1337 -- and we don't care about the rest` + 1

MySQL will ignore everything after the first occurance of -- as a comment and will set the value (actually, all vote values in the table) to 1337.


What is the advantage of using a symmetric cipher like AES to generate a keystream?

AES, by itself, is a block cipher: it accepts as input a "block" of 16 bytes, and produces a block of 16 bytes. But we want to use it to encrypt "data", usually long sequences of bytes, much longer than 16 bytes, so something else is needed; this is the mode of operation. The mode of operation defines how the input data is processed, and, in particular, what exactly goes into the block cipher proper.

The simplest method is to split the data into 16-byte blocks and process them independently of each other. This is called ECB. The usual penguin picture (see @drjimbob's answer) is a clear demonstration that there is something wrong with ECB, when processing "normal data". A better encryption mode is needed. Historically, OFB, CFB and CBC first gained popularity, then later on CTR was defined. All these modes make different things with the data and invoke the block cipher on different blocks. In CBC and CFB, AES is invoked of blocks which are a XOR of a data block with some produce of past processing; with OFB and CTR, AES is invoked on something which depends on the IV, key and block position, but not on the data itself.

With a lot of hand-waving, we can claim that in a good mode of operation, the raw data should not enter the block cipher "as is". The reason is the following: normal data has redundancy, so you can expect the source blocks to have repetitions (e.g. think of XML). However, the block cipher itself is deterministic, so if you call it twice on the same output, you will get twice the same output. This is the kind of information leak that a good encryption system should hide. In a mode of operation, the "hiding power" lies in the block cipher; the rest is mere data routing; therefore, in order to hide repetitions and other structural elements of the source data, the mode should be such that no two invocations of the block cipher shall send the same block to the block cipher. And this implies at the very least some pre-cipher processing.

Now CFB and CBC still "combine" the data block with the block cipher input, while OFB and CTR do this combination on the output only. We might argue that the latter method is superior because it allows precomputations: with OFB and CTR, one can "prepare" the pseudo-random string before having access to the actual data. However, this is rarely done, because buffering has its own costs. A much more important characteristic of CTR, that CFB, OFB and CBC do not have, is parallelization: given, say, a 160-byte message to encrypt, the 10 underlying AES invocations can be done simultaneously, provided that you have enough circuitry for that. You cannot do that with CBC, because you have to wait for the result of the encryption of one block to begin processing the next block (you can have parallel CBC decryption, though). High-bandwidth circuit makers love CTR mode (it maps well onto unrolled, pipe-lined AES implementations).

To sum up:

There is a need for a mode of operation more complex than ECB.
The mode should include some data pre-processing so that the raw data does not enter "as is" the block cipher. If the mode "directly encrypts the plaintext" (i.e. applies the block cipher on unmodified source data blocks) then it will have trouble hiding repetitions, and that's a problem with normal structured data.
There is no formal need that the source data enters the block cipher at all; the source data may enter the mix as a post-processing step. This gives some minor advantages, e.g. the possibility to precompute the bulk of the operations; if the post-processing is a simple XOR, it also makes decryption identical to encryption, which is nice when a system must do both (it saves code space and/or silicon area).
An important feature of good modes is the possibility to speed up things with parallelization. It so happens that the one popular mode which is amenable to parallelization for both encryption and decryption (that's CTR) also is a "post-processing only" mode. That's a coincidence; to my knowledge, there is no strong reason why it should be so. But it is nice nonetheless (as said above) so we will not complain.


ESET detected incoming connection to Rundll32

rundll32.exe is used to execute code from a dll, so -assuming it's the legit rundll32- you would need to check which dll is being run, eg. with ProcessExplorer.


What's the best way to enumerate log/sign in attempts?

You need to at least implement attempt counting at a per-account and per-IP level, so that password cracking is blocked regardless of whether it's one account and lots of passwords, or lots of accounts and a few common passwords.

The best way to do the count is to log the attempts to a database table, then compute the count at runtime using a query. You could use a set of queries like this to compute the counts:

// get the last successful login time.
// if this returns no rows, default it to 2000-01-01 00:00:00 or similar
SELECT TOP(1) attempt_time AS last_success_time
FROM login_attempts
WHERE success = 0

SELECT MAX(tmp.attempt_count) AS attempt_count // we want the highest count
FROM (

  SELECT COUNT(*) AS attempt_count
  FROM login_attempts
  WHERE
    attempt_time > $last_success_time // only count from the last successful login
    and success = 0
    and ip_address = $ip; // count by IP

  UNION

  SELECT COUNT(*) AS attempt_count
  FROM login_attempts
  WHERE
    attempt_time > $last_success_time // only count from the last successful login
    and success = 0
    and user_id = $uid; // count by user ID

) tmp;

Another thing to watch out for is proxies. Most people worry about them and attempt to use headers such as X-Forwarded-For to block source IPs. The problem with this is that X-Forwarded-For can be set by an attacker and used to get any IP address banned, simply by failing to log in. As such, you should check for existing bans based on X-Forwarded-For and the source IP, but never set new bans based on the header. This means that users attempting to evade bans by using a proxy will be caught if the proxy supplies X-Forwarded-For, but attackers can't spoof via it. It also has the side-effect of banning proxies that are used for attacks, which is a nice bonus.


I would urge you to revisit your premise.  If both endpoints will have an app on it, then your criteria for choice of algorithm are not valid: the app will be handling the encryption/decryption, not the user.  Public-key crypto can potentially provide better security in this context; for instance, it may enable trust-on-first-use (SSH-like) key management.  Also, I'd suggest that you start by first thinking about the threat model.  The first question should not be, what crypto algorithm do I use?  Your first question should be, What threats am I trying to defend against?

If you must use symmetric encryption for SMS texts, AES in CBC mode with ciphertext stealing is a plausible choice.  Ciphertext stealing will avoid waste if the message to be encrypted isn't an even multiple of 16 bytes.  You will still need an IV, which will take up some space.  To save space, you could send a counter, and use the AES encryption of the counter as your IV.

If there's any way you can avoid transporting ciphertexts over SMS, avoid it.  160 characters is very limiting.  Can you transport messages over the Internet?

If you can avoid tunneling over SMS, you might explore a model where the app has its own private/public key, and maintains a public key for each contact.  When contacting someone new, the app sends its own public key, receives a public key from the other person, remembers that public key, and sends the message encrypted with that public key.  This is of course vulnerable to man-in-the-middle attacks but may be easier to use.


What does "DECed" mean in Network Security?

It most likely means "Decoded" in this context, as "decoder" is the language keyword Fortinet uses to describe their anomaly detection:

  The FortiGate IPS uses protocol decoders to identify the abnormal
  traffic patterns that do not meet the protocol requirements and
  standards. For example, the HTTP decoder monitors the HTTP traffic to
  identify any HTTP packets that do not meet the HTTP protocol
  standards.

I would consider this a vendor-specific term rather than an industry term.

Another option might be "Decrypted", because Fortinet uses "dec" as their keyword for "decryption" (e.g., set dec-offload-antireplay {enable | disable}) but I truly think "Decoded" better matches the log entry you're looking at.


Include multiple pub keys in a x509v3-cert

No.
X509v3 as per RFC 5280, section 4.1 only allows a single subjectPublicKeyInfo field.
And this is the field that contains the public key. So no, you only get one.
MPK proposal didn't make it.
It seems that there was a proposal to introduce a Multiple-Public-Key (MPK) Certificate Format in 2001, but it never led anywhere.


Is MITM possible for Google services (TLS/SSL) as of today?

MITM is still possible if the attacker has sufficient control over the endpoint or in some cases if there is already SSL interception going on (not uncommon just by using AV).

If the attacker is able to either install a new CA on the endpoint or can use an existing custom CA already installed on the endpoint (as in case of the Superfish CA which was installed on Lenovo Systems) then he can do MITM. No HSTS or certificate pinning or certificate transparency will help in this case since these are deliberately disabled when a custom CA is used.

Similar MITM could be done in some cases if SSL interception is already in place. This is for example the case with many desktop AV software (Kaspersky, ESET, Avira ... all can do it and will often do it by default) and it is also common in companies. The necessary CA certificates for interception are automatically put into the trust stores and the client never sees the original certificate but must trust the SSL interception device/software to do a proper job. Unfortunately SSL interception systems commonly don't check for certificate pinning and certificate transparency in the first place, which makes it possible to use a different and compromised CA for the Google certificates then usually used. Moreover some SSL interception systems are of such a shoddy quality or configuration that they don't properly check certificates at all and can thus be fooled with certificates created by an attacker.

And of course SSL interception could be done if the attacker is able to compromise the device or software which does the SSL interception. Unfortunately systems like firewalls are not as hardened as one might hope and it is not uncommon that bugs surface which allow an attacker sufficient control over such devices.


How to implement CSRF protection with a cross origin request (CORS)

Our conversation started in the comment section, but I realized some inaccuracies in what I wrote. The sharing of cookies across domains is stricter than I thought at first. This should be a more comprehensive overview, and closer to what you might be looking for.

I will make a few assumptions:

You have two domains: foo.com (ui) and bar.com (api)
You want to prevent another domain like evil.com from causing side effects/reading responses from bar.com (CSRF + CORS protection)

Approach 1: Using CSRF tokens

This can be done using cookies, or simply using custom headers and storing the values in session storage or as a hidden input in a form. This means you manually need to send the CSRF tokens as custom headers with every request. Both from server and client.

Cookies will not be a good option here, since foo.com and bar.com are separate domains.

Limitations of cookies for different domains (that are not subdomains of the same domain)

foo.com --(request)--> bar.com

Any cookies stored in your browser with Domain=bar.com (that does not include SameSite=lax or SameSite=strict) will be sent along with the request assuming withCredentials=true

foo.com <--(response)-- bar.com

Set-Cookie is an illegal header in cross-domain requests, as mentioned (https://fetch.spec.whatwg.org/#forbidden-response-header-name).
Trying to set a cookie with Domain=bar.com using JavaScript while at foo.com will not work either.

bar.com --(request)--> bar.com

Here, Set-Cookie will work. Hence a redirect from foo.com->bar.com and then back will be able to set a cookie with Domain=bar.com. (So this could be a somewhat ugly/slow workaround)

Approach 2: Checking the Origin header

This is probably the simplest/cleanest option. (You won't need CSRF tokens if you use this method).

NOTE: The reason OWASP recommends only using the Origin header as a secondary measure to CSRF tokens is that the Origin header didn't yet support all common browsers when the recommendation was made. All common browsers have supported this feature for quite some time now. (It is currently ~3-4 years old)

*.com --(request)--> bar.com (CSRF)

Make sure that you check the Origin header of the incoming request in the bar.com-server. If this is either missing or https://foo.com, the request should be accepted. Otherwise, the response should be something like 403 (Unauthorized).

*.com <--(response)-- bar.com (CORS)

The response needs to have the proper CORS headers (assuming it was accepted, and the Origin header is not missing):

// Something like this, depending on your server language
response.setHeader('Access-Control-Allow-Origin', request.getHeader('Origin'))


Retrieving CSRF token from third party website form using XHR (JavaScript)

...  but what if someone uses XHR to retrieve the page containing the csrf token

The capabilities of such a cross-site XHR are restricted by the Same Origin Policy and could be extended by CORS. Without CORS explicitly allowing cross-site reading and also sending of the credentials (session cookie) it would not be possible for an attacker to do an XHR where the attacker can read the response in the first place and where CSRF tokens in the response are associated with an existing user session.

In other words: you will not be able to get useful CSRF tokens through your proposed cross-site XHR unless the server explicitly allows it.


This should be a comment, but it's a bit long.

  security on the client side

...is totally dependent on the application itself (which, within the context of the question, we don't need to know about/discuss) and the firewall/NAT (which you've told us nothing about).

  I figured out that it is not a security issue when my application opens ports

Really? Increasing the attack surface does not affect the security?

  or at least I cannot do anything against it

Try harder.

That you are using UDP across a WAN or the internet (between 2 fixed points) rather implies that:

1) the application uses very little bandwidth

2) low latency is critical

Hence, TLS or a challenge based authentication step would undermine these 2 requirements. This rather implies that you should be using a one time pad both to authenticate the requests and to protect against MITM.


Would using an input field for billing data but not storing or posting any of that data be legal?

There will be questions about handling of keys and potential client side attacks, etc. The only person who can give you a solid answer is a PCI-DSS QSA who understands enough implementation details to understand the data flows. I'm not a QSA but I've done enough PCI work to have an informed opinion.

My guess is that it does not count as 'handling cardholder data' from the perspective of your infrastructure, since in reality your servers don't see the data encrypted or otherwise (pls correct me if I understood incorrectly).

Also, in my personal view, it's unlikely this would be illegal, but it will have significant ramifications into PCI scoping, depending on how it ends up being implemented.


When hardening a LINUX system what command line tools would you remove first in order to make an attackers life really difficult?

Most of the native tools are necessary for system administration. There are very few that you could remove without being concerned that you'll need them one day.

You run a serious risk of extending outages or delaying projects when administrators are missing essential tools.

Instead, you should focus on:

Making it difficult for an attacker to communicate with the system (network boundaries, packet inspection, removal of unnecessary services)
Isolating hosts based on sensitivity of data (DMZs, network ACLs)
Blocking inappropriate communication (HIPS, network IDS/IPS, local firewall/iptables)
Preventing exploitation and limiting escalation (patching, app-specific hardening, least privilege users, chmod jails, sandboxing)


How to make my wireless internet or WiFi device secure for personal use?

Well, WiFi internet security is one of the major issues that the users are always complaining so I am going to share some quick tips to make your internet connection secure.

In the first step you need to open your router setting page you can only do that by typing “192.168.1.1” in your browser page and then enter your user name and password which can be given in the user manual of the internet router, usually each routers have different access.

Step 2. Create a Strong Password:
After logged in to your account all you need is to change your default password and to make it secure. Generally to change your password there are default values admin and password. Once you have done this your device will be automatically disconnect from the other devices.

Step 3. Change your SSID name of Network
Generally SSID name of the connection is defined as “default” or at the name of your internet brand for e.g “cyberetnet”. The change in the user name does not make your internet connection more secure but it can create difficulty for the others to know about the network they are connecting too.

Step 4. Enabled your network encryption:
Well, this option will prevent the other computer in your area to use your internet connection. All you need is to enable the encryption of your network.
In order to enable this feature you have to login to your wireless router security setting configuration page and choose its security method. For the older devices WEP is more reliable and for the other devices you choose WPA2.  To make a strong passphrase use small, capital, numeric and special characters to make it difficult for the other users.

Step 5. To Filter the MAC devices:
Every laptop, cellphone and other WiFi enabled devices have its own IP addresses and to prevent other users to use your device you can put the IP of only those devices which you wants to connect and others can’t connect to your device.
Almost every MAC address is hardcoded in network equipment, so one address will only allow one device to connect. If the attacker want to attack for spoofing first they have to find the MAC address of the device in which the network in connected and it very difficult for them to find.

Step 6. Upgrade your Router’s firmware, time to time: For this purpose you should have to check the manufacturer site time to time for the latest updates of your firmware. To find your existing firmware version you can check the router’s dashboard at 192.168.*.

All the above steps mentioned are enough to make your internet connection completely secure and safe from attackers.


How to ensure identity for server-to-server communication over IP

Basically you are trying to re-invent certificate based authentication since you only have an IP address and not a domain.
But certificate based authentication can be used without a domain too, for example by having the IP address as the subject of the certificate (if fixed) or by knowing exactly which certificate or public key inside the certificate to expect (certificate pinning, maybe even with a self-signed certificate).
In other words: just use TLS with certificates and don't invent anything new.


Yes, in a MITM scenario, an initial HTTP request is all it takes to successfully attack (if the user doesn't notice the missing HTTPS). And the only way to prevent this initial HTTP request is HTTP Strict Transport Security (HSTS).

As you know, HSTS means that your server's HTTPS responses include a HSTS header telling the browser only to use HTTPS, i.e. the client doesn't know that he must only contact the server via HTTPS before he gets the first HTTPS response.

But there is a feature of HSTS that solves this problem: preloading! All browsers supporting HSTS, also include a hardcoded list of domains, that must only be contacted via HTTPS. Everybody can submit their domain to be included in the HSTS preload list if they meet the criteria:

  Have a valid certificate.
  Redirect all HTTP traffic to HTTPS—i.e. be HTTPS only.
  Serve all subdomains over HTTPS, specifically including the www subdomain if a DNS record for that subdomain exists.
  Serve an HSTS header on the base domain for HTTPS requests:

  Expiry must be at least eighteen weeks (10886400 seconds).
  The includeSubdomains token must be specified.
  The preload token must be specified.
  If you are serving an additional redirect from your HTTPS site, that redirect must still have the HSTS header (not the page it redirects to).

Disabling HTTP on your server doesn't improve your security: the user won't know it is disabled before his first request and therefore will still make his request via HTTP and allow the MITM to respond to the request – even if your server wouldn't have answered it.


What issues might exist with TLS-OBC's emulation of Browser Certificates?

(TLS-OBC is not yet a RFC, just a proposal, and, as all drafts, can be subject to change.)

As presented, TLS-OBC is an extension to the SSL/TLS protocol. There is a scheme for such extensions, which can be added at the end of the ClientHello and ServerHello messages. Nothing related to TLS-OBC happens unless the client and then the server agree to use them. Possibly, some very old and buggy servers could choke on the ClientHello from the client, but the same can be said of every other extension and it does not prevent browsers from using, for instance, the Server Name Indication. So no real issue there.

Possible issues that I see with this draft include:

When TLS-OBC is used, the server should not send a list of accepted CA, and the client MUST ignore them anyway. This means that a given server accepts either OBC-type certificates, or standard certificates, but not both. Moreover, the server must make this decision before knowing the target path, so it is a server-wide setting.
The OBC is remarkably efficient at tracking clients -- that's its point, really, when it is used as a "strengthening of the cookie". This implies the same kind of privacy issues than cookies. I suppose that browsers implementing TLS-OBC will provide the same kind of choice than with cookies (i.e. a way to deny OBC usage with some specific servers).
Contrary to normal client certificates, OBC do not prevent institutional Man-in-the-Middle attacks (when a proxy servers creates a fake server certificate on-the-fly -- this assumes that an accomplice CA is installed in the client trust store, which is a relatively common setup in some big organization which want to monitor their employees closely). The "attacker" (possibly a legitimate attacker, as a sysadmin) just has to substitute his own OBC.

Mostly, I do not see clearly in what way OBC really increases security.


Issue 1 : You mention password encryption. Firstly why are passwords rather than salted hashes of passwords used? As for key rotation/expiration, I've seen (and coded for) policies like that. The longer a key is in use (and the more times it is used) the higher the risk it may become comprised/discovered. Some systems, for example Windows DPAPI automatically expire keys, SSL certificates have expiration dates after which a lot of systems will not use them to encrypt new data and so on.
Issue 2: Yes, that's bad. Incredibly bad.
The PCI compliance audit specs for the PAN state "Strong cryptography, such as Triple-DES 128-bit or AES 256-bit, with associated key management processes and procedures"
Rotation could be argued to be part of the key management process, and storing the key securely away from the data definitely is part a key management process.
Section 3.6.4 of the audit specs go further and state

Periodic key changes

As deemed necessary and recommended
by the associated application (for
example, re-keying);
preferably automatically At least annually


How would you construct an XSRF attack using an iframe?

The closest thing that matches your question is a Clickjacking attack (UI redress).

This is where you load another website within an IFrame that contains a button for the user to click. For example you (the attacker) could load the URL on a user's bank's website in the form https://www.example.com/money_transfer.aspx?to_account=12345&amount=1000000 where 12345 is your account number. If they are already logged into their bank and the response is a HTML form containing a single Transfer button, you could draw your own UI in your outer page that would replace the button with one that said Get a free iPad now!.

When the unsuspecting user clicks the free iPad button on your site, they are in fact clicking the Transfer button on their bank's website to transfer the money.

This sort of attack can be defeated by setting the X-Frame-Options HTTP header which modern browsers will obey and stop your website from being loaded within a frame.

Accessing the loaded IFrame using scripting is prohibited due to the Same Origin Policy - the only way round this if the user is using some old unsupported browser, or a browser containing a vulnerability where the origin is not properly checked.

The other possibility is a Rebinding Attack - the scope of this is usually limited as the cookies sent to the rebound IP will be the same as to the attacker's domain.


Update letsencrypt certificates without changing the private key

Create a certificate signing request (CSR) and let certbot renew that, using a command like this:

certbot certonly --csr csr.pem

The CSR contains your public key, so you keep the same key pair with this method.


Exploit LFI bug when a ".inc.php" is appended to the file name?

I think that it's not working because you're hitting a security check.

I ran strace to see what PHP was doing when including a file with a legal name, albeit nonexistent, and a file with an illegal name. It behaves differently:

lstat("/home/lserni/./legal.inc.php"...) = -1 ENOENT (No such file or directory)
lstat("/home/lserni/legal.inc.php"...) = -1 ENOENT (No such file or directory)
lstat("/home/lserni/legal.inc.php"...) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/lserni/legal.inc.php", O_RDONLY) = -1 ENOENT ...
write(2, "PHP Warning:  include(): Failed "..., 154
PHP Warning:  include(): Failed opening 'legal.inc.php' for inclusion...

write(2, "PHP Warning:  include(): Failed "..., 148
PHP Warning:  include(): Failed opening 'illegal' for inclusion...

So from above you can see that the legal file name gets checked on the file system - twice - and an opening attempt is done even if PHP sees that the file doesn't exist (this rated 0.2 kWTF) and issues an error.

The illegal file name issues the same error, but without even trying to check whether the file might be there.

I'm quite confident that if I check in PHP sources I'll find some test that fakes a "this file isn't here" error, when actually PHP decided to not open the file no matter whether it was there or not.

Remote file inclusion

The "file inclusion" vulnerability means that you can send to the server something that will cause it to include() (and execute) a file of your choice. The file can be local (Local File Inclusion or LFI) or remote (RFI).

To exploit a RFI you need a remote file on a different domain; not the one you're testing, but another.

This remote file, not the local ones, must be under your control.

The content of the remote file must be such that the vulnerable server will include it; that is, it must be valid PHP.

The remote file, once included, will execute inside the vulnerable server, and so will have access to its local files (but no longer to the remote ones).

So if the remote file displays the instructions "include('index.php');" or die(file_get_contents('index.php'));, it will read not the index.php of the remote server, but that of the vulnerable server (which is what we want to do).

At the same time, the remote file will execute on the remote server, so we want it to execute some PHP code that will display another PHP code.

For example this is the content of http://www.serni.org/i.inc.php:

<?php
    // The outer code is just a print.

    print <<<INNER_CODE
<?php
    // This is a sample remote file inclusion vulnerability.
    // It will simply count how many files there are in the
    // vulnerable script's directory.

    \$files = count(glob('*.*'));
    print "This folder contains {\$files} files.";

    // Just sayin'.
    // shell_exec("FORMAT A: /Y /AUTOTEST");
INNER_CODE;

If you use http://www.serni.org/i.inc.php as a resource, and the RFI works, the vulnerable page will return the count of files in that directory.

G1mm3 th3 cod3z (TL;DR;DT)

http://example.com/challenge/mypage.php?page=http%3A%2F%2Fwww.serni.org%2Fi

How to defend

Obviously, sanitize your inputs. Or better, whitelist them, and only allow very simple combinations. And unless you need to include remote resources (which happens), set allow_url_fopen to false.

$allowed_resources = '#^[A-Za-z_0-9-]+$#';
$ok = false;
if (preg_match($allowed_resources, $resource)) {
    $actual_file = realpath("external_resources/{$resource}.php");
    // We could verify that actual_file matches _SERVER_ROOT/external...
    if (file_exists($actual_file)) {
        include $actual_file;
        $ok = true;
    }
}
if (!$ok) {
    // We don't want to send back to clients whatever they sent us; that way lie XS vulnerabilities.
    $resource = basename(strip_tags($resource));
    // Mess a little with people's heads.
    die("Warning: include() [function.include]: Failed opening 'C:\\Inetpub\\Resources\\{$resource}.aspx' for inclusion (include_path='C:\\;C:\\WINDOWS;C:\\Program Files\\Nginx;C:\\Python\\Tornado5\\modules')");
}


What is the state of 3G data cryptography?

I understand that data over 3G uses the KASUMI cipher, which has been compromised, but practical applications of that are not known to be in the wild. Is this still true?

Seems like it. But there are detailed reports and researches on the subject. (see here)

  If we can trust the connection between the tower and the datacenter, can we trust the connection between the tower and the device?

No. The data between the tower and datacenter runs on physical cables and all access to any component on the infrastructure is locked in a box with access only to the technicians (This is the usual case which I assume applies in this situation). The data between the tower and the device is in radio waves which can be sniffed.

  If this is still true, theoretically there might still be a way to compromise that radio connection. How complex would an exploit like that have to look? Would it be able to run on a femtocell using modified firmware, or might it require more complex hardware?

You can preform the attack with a few methods:

Sniff the information being sent between the device and the tower and then decrypt it.
Get close to the device with a stronger cell signal and cause the device to connect to you and then redirect the traffic to the original cell (or don't) causing you to be able to preform as a man in the middle.

Either way all attacks on cellular devices and cellular infrastructure are very hard, time consuming and expensive (a personal cell can cost around $5000), so your biggest threat is a very well funded and professional hacking team or a government of some short.

My suggestion is to stay with the encryption that exists but if you are making any TCP/UDP requests from the device you should add a private encryption that will act as another encryption level.


What exactly is a "Combo List", and why is this site providing them for free?

Combo is short for combination, so combo lists are lists containing combinations of usernames/emails and passwords.
They are used for bruteforce attacks. The benefit compared to separate username and password lists is that combo lists are expected to contain a higher likelihood of success.
They may eg stem from data leaks or previous successful bruteforce attacks. The idea is that they (used to) work on some websites, and because users reuse passwords, they may work on other sites as well.

Why would they give out this info to the public like this? What's in it for them?

Why do people share anything with others? Fame, recognition, helpfulness, money (via ads), boredom?

Why would they want more spammers to send e-mails to these victims of data breaches?

It's not so much about spamming (lists of email addresses would be enough for that), but about gaining access to other users accounts. Eg to gain free stuff (say a netflix account) or for more nefarious purposes (stealing money, credit cards, etc).


How can I protect my WiFi if I have two routers?

There is not so much you can do with securing wireless network from a router standpoint, but key points to hardening are:-

Change default password.
If available use WPA, not WEP.
Disable remote administration
Change the default SSID name
Enable router firewall
Disable SSID broadcast
Enable wireless MAC filter


Safely transfer UserID among different Subdomains

First and foremost do not write your own protocol for this!  Other people have this exact same need and they use oAuth!

If you just need to know that they are connected an oAuth 2-legged is perfect.  If you need to share more information about this user then use 3-legged oAuth.


RubySMB::Error::CommunicationError: Read timeout expired when reading from the Socket (timeout=30)

That module doesn't support Windows 10 targets. You can see from the targets that it supports Windows 7 and Server 2008.
msf6 exploit(windows/smb/ms17_010_eternalblue) > show targets

Exploit targets:

   Id  Name
   --  ----
   0   Windows 7 and Server 2008 R2 (x64) All Service Packs

msf6 exploit(windows/smb/ms17_010_eternalblue) >

The ms17_010_eternalblue_win8 module (despite it's name) works on Windows 10. Says it was tested successfully on Windows 10 build 10240 and build 10586 so the build of your target is quite a bit newer but it may work.
FYI, it's a known issue that these modules are separate and targeting is difficult which is why there's an effort to combine them into one.


What resources/organizations should we submit applications to for testing, to prevent Anti-Virus "False-Positives?"

Start off by scanning with VirusTotal (a Google-owned malware database), and see which AV software considers it a threat.

Proceed with contacting all the antivirus companies that flagged your software as a threat in order for them to whitelist your app. The Kaspersky page you mentioned has a registration form link, use it.

Here's Norton's page dedicated to the same purpose.

Keep searching for the relevant pages of each company on Google until you've covered them all.

Scan your app occasionally with VirusTotal to see if there was progress on your applications.

While tedious, it's the best way to my knowledge.


What should I do when classified information stayed on a unauthorized laptop?

This an incident you need to handle and I am guessing that a standard response has not been detailed in your documentation.

Realize that your system is malfunctioning.  It is not operating the the way it was intended to.

Isolate your system [meaning your network(s) and physical facility if possible] to prevent the data from leaving your system. Take care to cause as little change to individual assets as possible. You want the state of the assets to stay constant until you can assess them.
Identify the source or sources of the data leak.
Isolate the leak source or sources to prevent further contamination in your system. Again, try to preserve there current state as much as possible. This will help you identify assets contaminated by the source.
Identify all assets that may have been contaminated by the source or sources.
Isolate the potentially contaminated assets. I know it is getting repetitive, but preserve the state of each asset as much as possible. These assets will help you assess the extent of the contamination.
Treat all potentially contaminated assets at the level of the contamination. In this case TS.
Verify that the remaining assets are not contaminated.
Breathe, have something to eat or drink, take a short break, because the rest of your day/week/month is going to be painful.
Discuss and plan remediation of contaminated assets. Planning well here will allow you to understand the scope of the problem, who is impacted, and how long you expect it to take.
Execute the remediation plan and periodically report on progress.
Pain
Vacation

  Has anyone ever had to deal with an unauthorized laptop accidentally getting Top Secret level data on it?

I have not. I have been involved in containment and remediation of sensitive data.

  How did you quarantine the system?

I have not been involved with the primary contaminated system, only secondary systems.

For systems suspected of contamination:

Posted restricted area notice sign on the door.
Locked the door.
Removed network communications.
Shutdown the system to preserve as much of the current state as possible.
Analyzed the system to check for presence of data in question.
If detected, moved the system to a secure area for sanitization.

  Were you required to turn in the entire laptop or were you able to destroy/format the HDD?

The agency involved will determine the action to be taken, and the policies and practices may vary from agency to agency.

I do not have personal experience, but given that TS is described as 'Such material would cause "exceptionally grave damage" to national security if made publicly available.' I would expect that every physical component of the item formerly known as a laptop will be crushed, smashed, melted, dissolved, extruded, shredded, and used as target in a artillery range.

The consequence of the release of the information compared to the value of the laptop, the other software and data on the laptop, and any other adjacent items of value, makes it clear that preventing the release of the data is worth the cost of total destruction of the laptop.


Vulnerability scanner shows SQL errors were disclosed.How Severe it is?

Not all SQL errors can be exploited, however you need to investigate why the SQL error was generated. Often it's a sign of bad input validation, even when not exploitable (by you) it should be fixed. Furthermore, in production environments, error messages should be generic and not disclose any details about the error or your system's configuration.


Does insert only db access offer any additional security

The short answer is "Yes", it does offer some additional security as you make it more difficult for an attacker to gain the information these outside users are entering.

The long answer is that a focused attacker could:

use the compromised web nodes to hijack your outside users towards his server or inject malware, likely with little difference to be noted in the web interface as he has access to your page sources
use the compromised web nodes to capture future data that is entered by outside users and forward this data to his servers for capture, thereby over time replicating parts of your database
traverse from the web node to the internal network over time, for example through new security holes found in the database interface or any other interface you expose to the web nodes


How can Alice and Bob prove that they share a file?

Carl can ask Alice and Bob (independently) to calculate hashes of specific fileparts and compare the results. For example C asks A to calc h(f[0-100]) and receives h' then C asks B to do the same and B returns h''. If h' == h'' they both have the same knowledge about this part of f. You can repeat this for different sections of the file.

Notice: If A and B cooperate (and want to trick C) and only one of them has the file there is no way for C to tell if they both have f or of they're just cooperating.


Create Public Key using OpenSSL instead of PuTTYgen for PKCS#8

The OpenSSH format is unsurprisingly supported by OpenSSH tools. (The OpenSSH public-key format, used in authorized_keys and with a prefix added in known_hosts, isn't itself a "de jure" standard, but is a trivial modification of a public-key encoding within the SSH2 protocol which is standardized.)

Less obviously, OpenSSH uses OpenSSL format(s) for private keys, although they recently (6.5) added a optional format of their own. Thus a private-key file you generated with OpenSSL is an OpenSSH private key, and OpenSSH can convert it to an OpenSSH public key with the -y option of ssh-keygen. See http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/ssh-keygen.1?query=ssh-keygen .

(Dupe of https://stackoverflow.com/questions/10271197/openssl-how-to-extract-public-key
and https://serverfault.com/questions/52285/create-a-public-ssh-key-from-the-private-key .)


NIST publishes a lot of test vectors. Including for HMAC (near the end of that page). In the file contained in the Zip archive, the vectors for HMAC/SHA-256 ought to be the ones with the parameter "L=32".


The issue you will have here has to do with L2 and L3 boundaries, and how MAC addresses are exposed.

When a L2 packet is handled by a L3 gateway, especially one which applies NAT to it, this will cause the packet to be re-transmitted by the l3 gateway rather than forwarded as is. This means that to the public world IE your remote location you will see the ASUS router as the sources and destination of the conversation, and the remote endpoint will not know what is behind the ASUS router. This is contrary to a L2 only network in which the logic is much simpler, the MAC address is compared with an ARP table, or list of ports and the MAC addresses associated with that port. The ARP table is populated by the conversations a network client makes when interrogating the network when first connected. The switches then effectively replicate the data packet and forward it to the destination port until it arrives.

The best you can do is restrict it to a remote IP, or you could layer on some security higher in the network stack, like in the session, or the application itself.

The problem with MAC addresses, is that they are readily forged. It's just security through obscurity because guessing which MAC to use wouldn't be trivial. Typically people use SSL keys or other harder to impersonate unique identifying mechanisms to ensure good security. For example, you could have a VPN which only allowed members to connect if they had a correct SSL private key which was authorized.

On a semi-related note - I highly recommend getting a Dropcam for watching a baby at home. It handles the security issue well and gives great HD quality.


Are partially typed passwords a potential security risk?

Corporate espionage is a thing.

There could be a security risk if someone has seen you typing your password, or guesses the last two characters. It's not all that difficult to notice people's keystrokes and subconsciously remember them, especially the last few keys.

In the case of corporate espionage, someone might want to watch you type your password, and they might remember it.

  or maybe save the state so you can keep retrying from that partially completed point?

You have to admit, given the circumstances, this seems like next-level tinfoil hattery. I can just picture a guy in a grey suit walking up to your desktop, looking for your 20+ GB virtual machine disk, plus accompanying configuration data within a couple minutes, and taking it to a seedy cubicle in the corner of the office, then madly brute-forcing while cackling maniacally:

Let's take off the foil for a second. If you are running a virtual machine, then it's quite possible. You could save the state of the virtual machine at that point, and keep trying. The likelihood of this happening to you during a coffee break is pretty much zero. Same with the app state, only not as unlikely as a virtual machine.

With the virtual machine, a colleague would have to copy the contents of your virtual hard-drive, plus the accompanying settings, and mount it. More than likely, this would be in excess of 20 GB. Copying this virtual drive in such a short time while other people are around seems quite unlikely.

Someone will notice something.

What if this were a web page login as opposed to a desktop app?

Let's put on our tinfoil hats and see what we can do to retrieve the partially-typed password using only readily-available tools. Put yourself in the shoes of the attacker: how would you quickly get the password before the coffee break is over?

Using the developer console, you can modify the web page to change this:

<input type="password" name="pass" id="password"/>

To this:

<input type="text" name="pass" id="password"/>

(Removed jQuery as suggested by Doyle Lewis)
We can also get the values through the console input: you can use a variation of these (F12 > Console > Enter input):

console.log($("#password").val()); (jQuery)
console.log(this.pass.val);
console.log(document.getElementById("password").value); (dom)

Apparently Windows 8 and Windows 10 Enterprise have an "eye" icon that allows you to reveal the plain-text password when holding down the eye button. This becomes an even bigger threat when someone else can just click that one button, bypassing all of the effort used in the examples above.

But why would this be a potential security risk?

Re-equipping our [Tinfoil Hat (Mythic Warforged)], let's assume a worst-case scenario:

With your username and password, in an enterprise setting where it definitely isn't difficult to find your username (usually your badge ID, or email username), a malicious colleague can attempt to impersonate you on the network. For example:

Your corporation has WiFi access which requires your employee badge number and password to sign in.
Malicious colleague logs onto the corporate network using your credentials, on an unauthorized device, and then wreaks havoc / steals things without it leading back to them. Most security policies should require device registration first, but there are unfortunately ways around that.
You get blamed. It looks like you did it. And the spy who screwed things up may get away scott free.

How do I protect against this?

This very unlikely, but possible attack, and many other attacks that require physical access to your machine (not including hardware-based infections), is completely mitigated by locking your workstation before getting up, and not entering partial passwords. Make this your habit, and you won't have to worry about anyone doing something like this.

Don't get complacent, though.


The "hiding" issue with GET-vs-POST is logging, so yes, you want to avoid including anything in your GET URI that you wouldn't want to see saved in a logfile.

One common workaround for your problem is to use the HTTP headers to communicate information for a GET request.  It's very common for credentials or session cookies, but may also be used for search strings or lookup indexes for the data you're GETting.  Like the POST body, headers are generally not logged, so it's "more secure" then putting them in the GET URI.

REST is a wonderful theory.  Implementing it can be disillusioning.


Is it possible to buy multiple hardware MFA devices with the same key?

If you use the virtual one, you can print the QR code and/or write down the secret. Multiple Google Authenticators can scan the same code, or you can type it in manually to Google Authenticator.


Struggling to profile the query behind a SQLi vulnerability

I've found a SQL injection vulnerability in a form since the use of special characters in one of the form field's values returns errors.

This is an incorrect assumption. Errors could indicate a poorly developed application which may or may not include a SQL Injection. To say that you have found SQLi at this stage is premature.

  The error specifies that an incorrect number of parameters were provided to some internal function.

I would strongly recommend searching for the error message and using it to fingerprint the application. If it is a raw error message, you could find out the app/web-server/DB component that generates it.

  I've tried a browser tool to profile the query hoping it would paint a picture of what the query looked like ready for demonstration of how it can be exploited but it failed to identify a vulnerability at all.

SQL Injection tools are now fairly mature. If the tool doesn't find anything, it is likely not a SQL Injection, or it is possible you are not using it correctly. Are the payloads generated doing what you want them to do (are they probing the form correctly)? What responses does the tool show?

OWASP's guide is a great place to start looking at for a manual testing methodology. Depending on what you observe, some kind of "blind" exploration is likely required, perhaps you should look closely at UNION, boolean, or time-based detection techniques. Alternatively, throw sqlmap or havij at it, if this is within the scope of the pentest.


No limit of characters in name field - Any risk?

It is not really relevant if there is a size limit in the HTML form fields. Such size limits are only a client side restriction which is also only enforced by some clients (browsers). As with other checks done only at the client-side it is easy to write a client which ignores such restrictions.

All what is relevant in this case is how the submitted data are handled on the server side and this can not be determined just from looking at the HTML at the client side.


How to gain root privilege after injecting code using a buffer overflow vulnerability?

There are many ways to get to root. You need to consider exploits which get you root, as well as those which get you access at a lower privilege in conjunction with a privilege escalation exploit.

Generally what you need is an exploit in a service run as root, or another privileged account.

As cremefraiche noted, you should have a good read of cve.mitre.org to get some idea of the variety.


The biggest benefit is reporting. Without central control, you have no idea if an endpoint is updated, having problems, on an old version of a client, whether there is a high-risk endpoint getting hit, or if there is a certain endpoint with a higher than average number of hits, etc.

If your AV solution allows you to distribute IoCs, then yes, that's a value, but that's not normal.

Endpoints should update themselves, so that's not an issue.


Transport Layer Encryption vs. Application Layer Encryption

This is a question about scope and application interaction. So where one is better than the other depends on the scope of access of the data.

With application layer encrypt the data is only view able in your applications memory space. If this is what you need then application level encryption is the way to go. However when sent to another application, that information is encrypted and they can't view it. This is useful in JSON Web Tokens where the server encrypts and de-crypts the information for checks and balances while preventing other layers of the OSI model from modifying it.

Transportation layer encryption though is akin to TLS/SSL/SSH and such. It's where you encrypt it in transport so people can't listen in unless they are accessing the shared memory on the machine that would release the information. This is useful for sending user input to a server that doesn't need to be encrypted, but still having it view able in a web page.

To condense those explanations down a little further:

Application layer encryption should be used when NOTHING else should have access to the data even on the same machine.
Transport layer encryption should be used when you don't want people listening into the data when it is in transport and no longer on the machine it was created on.

Now I mentioned a website example earlier and that's the perfect way to think about it since all OSI models apply to that on the server side.

Websites are data and in transport if they contain user specific information need to be encrypted but should still be view able to the user when the page displays again on the application layer on their end. This is where the transport layer encryption happens.

However to protect against attacks when a user is sending information back they often include a check in the form of a JSON web token or CSRF cookie/field that is not view able by the client, and is encrypted in the application layer so that no one else can view it or modify it. Then if it's the same when it comes back and the information inside of it checks out, they know it's still valid and can honor it on the server side.


There are many many things you can do to ensure the security of your PHP application whether it is OO doesn't really make that much difference.

You could start by running some automated php auditing tools to pick up on the really obvious issues see here
Also more information about security attacks on php web applications
Basically you want to at least try and secure against the top 10 application security risks, but this is only a start.
Securing the application is only the first step you need to make sure that overall your server and every other part of your system is secure.


Is a browser with disabled scripts and disabled java enough against malware

There is a lot of exploits against libjpeg for sample. Who could  be triggered even without javascript.

100% sure don't exist anyway, but. Each functionality present in your host are subject to security faillure and related exploit.

While quantity of faillure existing or maybe existing is related to complexitiy of software, more a functionality is complex (rich), more they are subject to hold some non discovered vulnerabilities.

Most faillures in statics libraries and small utilities like libjpeg or video codecs seem already reviewed, chance to find new non discovered vulnerabilities in such libraries are very smaller than chance to find vulnerabilities in complex programming language (like javascript). Note that in propretary libraries like flash or java, who depend from a hierarchical decision struture may be even lot more considerable.

So the right choice for your configuration is to do between no trust ( su - nobody -c "links" or even better: keep your pc down and cut every cable! ;-) and feel good  ( all plugins and codec automatically downloaded and installed... )


Is PHP unserialize() exploitable without any magic methods?

The exploitability of PHP object deserialization depends solely on the available classes (standard classes as well as custom classes), their methods and behavior, and whether it is possible to get one of these exploitable methods triggered.

Note that the exploitable methods may not be that trivial. You may need to create complex object structures using multiple, nested objects to trigger a certain behavior. The number of exploitable methods or their behavior may also change during the time. So even if you may not be able to exploit it today, someone may sometimes be able.


What are NoScript surrogates and should one disable them for more privacy in browsing?

Assuming that you have already totally blocked access to the trackers then it doesn't matter to your privacy.

However, it may matter to your usability of some web sites. The scripts are there to allow sites to work that otherwise rely on the scripts being blocked. If all your sites work, you don't need them.


XML entity attacks are attacks against the server, not the client. CORS headers like Access-Control-Allow-* are only relevant to the client. You completely ignore them when testing for purely-server-side vulnerabilities. Just use Burp Suite / ZAP / Fiddler (or curl, or your browser's dev tools, or nc) to change the content-type header and the payload.

With that said, the likelihood that a server which expects only JSON will see a request containing XML instead and decide "better load that into an XML-parsing library" rather than "WTF is this nonsense 400 BAD REQUEST" is... very low.


No,  what you are asking is fundamentally not possible.   The primary function of the MAC address sublayer is allow for the communication of numerous devices(OSI Layer 2) via a physical medium (OSI Layer 1).  Nothing is preventing an attacker from assigning their NIC an arbitrary MAC address value.  One side effect is that your DHCP server will then issue the same IP address to the same MAC for each request,  even if the request originates from an attacker's machine. This is not to be confused with ARP spoofing,  which is useful for MITM attacks, and can be prevented.

Really what you are looking for is a VPN. This can be used to allow only trusted hosts to communicate.


How can one centrally manage / audit AWS resource-based policies

You should be able to use AWS Config for this to ensure that only certain policies are allowed.  Within Storage, you have the following options:

ebs-snapshot-public-restorable-check
efs-encrypted-check
elb-deletion-protection-enabled
s3-bucket-blacklisted-actions-prohibited
s3-bucket-logging-enabled
s3-bucket-policy-grantee-check
s3-bucket-policy-not-more-permissive
s3-bucket-public-read-prohibited
s3-bucket-public-write-prohibited
s3-bucket-replication-enabled
s3-bucket-server-side-encryption-enabled
s3-bucket-ssl-requests-only
s3-bucket-versioning-enabled

For your usage case, I think you can use s3-bucket-blacklisted-actions-prohibited and block for example all s3:GetBucket* policies.

You can also use these rules in CloudFormation templates.


Does Yubikey 4 support multiple OpenPGP encryption keys or only one?

Then OpenPGP smart card standard explicitly reserves each slot to the respective usage. If you use the Yubikey as OpenPGP smart card (so it can be used with GnuPG, ...), you will not be able to upload keys to "incompatible" slots.

I just tried to upload a signing key to my card/Yubikey (which just holds an authentication key up to now), and was only able to choose among the signing and authentication slots (the encryption slot was not offered).


Signing CertificateRequest with special privileges

I had to change usr_cert fields like: keyUsage and
extendedKeyUsage to add special policies.

Additionally there is possibility to change nsCertType to change the type of certificate.


PGP messages come in a raw binary format that comprises multiple packets as specified in RFC 4880. There is nothing exciting about the syntax. For instance, every packet in a message consists of a header and a body with the first byte of the header being the header tag, etc. You can dissect a PGP message just like you would with a TCP packet.

What you identified as "one big block of base64" is called an ASCII armor. As the name suggests and @SteffenUllrich pointed out, it protects the message from getting corrupted during transfer by representing it with printable ASCII characters. All it does is base64-wrapping the OpenPGP format.

If you wanted to parse an ASCII armored message you would first base64-decode it and then parse the contained binary stream according to the syntax specification.

From section 2.4 of the RFC:

2.4.  Conversion to Radix-64

   OpenPGP's underlying native representation for encrypted messages,
   signature certificates, and keys is a stream of arbitrary octets.
   Some systems only permit the use of blocks consisting of seven-bit,
   printable text.  For transporting OpenPGP's native raw binary octets
   through channels that are not safe to raw binary data, a printable
   encoding of these binary octets is needed.  OpenPGP provides the
   service of converting the raw 8-bit binary octet stream to a stream
   of printable ASCII characters, called Radix-64 encoding or ASCII
   Armor.


The alternative is to buy all the AV which are used in virustotal.com and build a similar system for local use. Don't forget to cut it from the internet because AV might phone home not only to get new signatures but also to report interesting new findings.

Apart from that there is an underground market for such checks, see http://www.wired.com/2009/12/virus-check/, but as you might imagine this is primarily used for illegal activity.


What actions should be taken by site according to Data Protection legislations?

When talking about data protection laws the first thing to note is that they are laws so you should check with a lawyer if in doubt.

However, with things such as the UK laws (which you seem to be asking more specifically about) the guidance the information commissioner has on their website is pretty straightforward and nicely enshrines a lot of the principles that you'll find in other data protection laws in the EU (as the Data Protection Act is the enshrinement in UK statute of the EU Data Protection Directive).

http://www.ico.gov.uk/for_organisations.aspx

For the UK, there are a couple of quick pointers which you should consider (and there's more info on the website I mentioned. Here's the 8 "principles" that are set up by the act, shamelessly copied from the ICO's website.

  Personal data shall be processed fairly and lawfully and, in particular, shall not be processed unless –

  (a) at least one of the conditions in Schedule 2 is met, and
  (b) in the case of sensitive personal data, at least one of the conditions in Schedule 3 is also met.

  Personal data shall be obtained only for one or more specified and lawful purposes, and shall not be further processed in any manner incompatible with that purpose or those purposes.
  Personal data shall be adequate, relevant and not excessive in relation to the purpose or purposes for which they are processed.
  Personal data shall be accurate and, where necessary, kept up to date.
  Personal data processed for any purpose or purposes shall not be kept for longer than is necessary for that purpose or those purposes.
  Personal data shall be processed in accordance with the rights of data subjects under this Act.
  Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.
  Personal data shall not be transferred to a country or territory outside the European  Economic Area unless that country or territory ensures an adequate level of protection for > the rights and freedoms of data subjects in relation to the processing of personal data.


Site preventing user from closing tab/closing browser

Update: this is no longer a concern on Firefox (29+) and Chrome (version? not sure if it was ever an issue there). Firefox will only display a single dialog now.

Firefox 31 additionally makes the dialog non-modal, and will also close the window if you press the close button a second time.

Unfortunately, IE11 still shows multiple dialogs. I'm not sure if Microsoft is aware of this issue.

The method is pretty simple, actually. If you inspect the source, you'll see a lot of repetition of this line:

<iframe test="test" srcdoc="<script> window.onbeforeunload=function(env){ return 'YОUR BRОWSЕR HAS BЕЕN LОCKЕD. АLL PC DАTА WILL BЕ DЕTАINЕD АND CRIMINАL PRОCЕDURЕS WILL BЕ INITIАTЕD АGАINST YОU IF THЕ FINЕ WILL NОT BЕ PАID.';} </script>" src="au/close.php"></iframe>

Basically, they have a whole bunch of iframes and each iframe can trigger the 'are you sure you want to leave' message once. It's not infinite by any means (as Braiam said, you can just hold down enter on the leave page), but it's probably enough to trick some people.

This is arguably behaving as intended - though it may be better to add one of those "don't show again" checkboxes, much like they do for alert popups.

Another way to prevent this kind of thing is to disable JavaScript on sites you don't trust. NoScript works well. This can, however, be somewhat annoying and/or break sites at times.

For the interested: Chrome actually displays one long dialog. That comes with its own problems - and this is a browser bug - the buttons get pushed out of the bottom of the page (happens with any too-long Chrome popup). You can still hit enter. The Chrome dialog seems to be initiated by a different alert popup, and it actually doesn't seem to display the iframe unload text at all - it's likely they added this specifically to trap Chrome users:

<script type="text/javascript">window.onbeforeunload = function(env){var str = '\n\nUw br' + 'оws' + 'еr is gе' + 'blо' + 'kkе' + 'еrd.\n\nAl' + 'le P' + 'C dа' + 'tа zu' + 'lle' + 'n wо' + 'rde' + 'n vа' + 'stgе' + 'hou' + 'den e' + 'n st' + 'rаf' + 'rес' + 'htе' + 'li' + 'jk' + 'е pr' + 'ocе' + 'dur' + 'es zu' + 'lle' + 'n wо' + 'rd' + 'en ing' + 'еlе' + 'id te' + 'ge' + 'n u al' + 's d' + 'e bo' + 'еt' + 'е ni' + 'et wo' + 'rd' + 't be' + 'taa' + 'ld.\n\n';
        alert(str);
    return str;
}
</script>

Again, it's nothing more than a scary popup that seems to be impossible to get rid of. Malicious? Yes. Actually dangerous? Not really. As long as you don't fall for the scam.

Also of potential interest is that they do display your public IP and approximate location. This is a fairly standard scare tactic on these scam sites and really isn't anything special - any site you connect to can get your public IP, and public GeoIP databases can usually provide the approximate location. If you're really worried, go get a VPN or anonymous proxy to connect through.


Is there a real-world example of SSD data recovery?

Recovery is only possible under certain conditions:

have an older SSD with no TRIM support
or
have Windows XP (as it does not support TRIM) or another old OS with no TRIM support
or
you connect the SSD as an external hard drive via USB port.
or
AHCI / SATA interfaces are not detected in your old MB - you use legacy mode/IDE mode
or
you have a RAID 0 setup

Those are the happy cases. Any decent software will be able to recover your files.

The now-days most encountered case is when you have a new SSD with TRIM enabled. In this case, data recovery is a no-go, because when TRIM is enabled, the erase action is performed immediately. TRIM will purge both the data and the link to it, so practically, it’s gone; it’s simply decontaminated and empty, flagged as ready-to-use.

In some situations, Self-Encrypting Drive (SED) and ATA Secure Erase have been found not to function, just like Bitlocker encryption. In such a situation, data is also recoverable. But in a case of fully encrypted drive with a 3rd party reliable tool, nothing will be recoverable.


non-cryptographic hash function with output changing just as much as the input

Not sure if there existing hashes that do this.  The reason being when hashes were developed, the requirement that any change in the inputs would create a large change in the output was a basic requirement of a hash.  That being said I can purpose a way to do it.

An example would be a hash that just counts the occurrences of each letter in the input. For simplification let's say this hash only takes lowercase alphabet characters.  So the length of the hash will be 26.  Each position in the hash would refer to a different character. So the first position would total up all the a', the second would hold the total of the b's...

hello world

would hash to

00011001000300200100000000

because there are no a's, no b's, no c's, 1 d, ect

a change to

hello worlds

would hash to

00011001000300200110000000

The only difference would be the count for the "s".

Obviously there are many problems with this such as you can only have a maximum of 9 instances of each letter, but this is only an example to show how a hash could show small changes in output for small changes in the input.


How can I decode a message that was encrypted with a one-time pad?

One-Time Pad is unbreakable, assuming the pad is perfectly random, kept secret, used only once, and no plaintext is known. This is due to the properties of the exclusive-or (xor) operation.

Here's its truth table:

A xor B = X

A | B | X
0 | 0 | 0
0 | 1 | 1
1 | 0 | 1
1 | 1 | 0

Number of 0s in column A = 2
Number of 1s in column A = 2
Number of 0s in column B = 2
Number of 1s in column B = 2
Number of 0s in column X = 2
Number of 1s in column X = 2

Note that it introduces no bit-skew - the number of 0s and 1s in the inputs are equal to the number of 0s and 1s in the output, i.e. two of each. Furthermore, if you know only one element from a row, you cannot predict the values of the other two, since they are equally probable.

For example, let's say we know that X is 0. There's an equal probability that A = 0 and B = 0, or A = 1 and B = 1. Now let's say we know that X is 1. There's an equal probability that A = 0 and B = 1, or A = 1 and B = 0. It's impossible to predict. So, if you only know one element, you cannot possibly determine any information about A or B.

The next interesting property is that it is reversible, i.e.

A xor A = 0
B xor B = 0

A xor 0 = A
B xor 0 = B

A xor B xor B  =  A xor 0  =  A
A xor B xor A  =  B xor 0  =  B

So, if we take any value and xor it with itself, the result is cancelled out and it always results in 0. This means that, if we xor a value A with a value B, then later xor that result with either A or B, we get B or A respectively. The operation is reversible.

This lends well to cryptography, because:

xor introduces no bitskew
xor has equally probable inputs for any given output
given any two of A, B, X we can compute the third

As such, the following is perfectly secure:

ciphertext = message xor key

but only if message is the same length as key, key is perfectly random, key is only used once, and only one element is known to an attacker. If they know the ciphertext, but not the key or message, it's useless to them. They cannot possibly break it. In order to decrypt the message, you must know the entire key and the ciphertext.

Keep in mind that the key must be completely random, i.e. every bit must have an equal probability of being 1 or 0, and be completely independent of all other bits in the key.

This actually turns out to be rather impractical, for a few reasons:

Generating perfectly random keys is hard. Software generators (and many hardware generators) often have minuscule biases and odd repeating properties. It's almost impossible to gain truly random data in anything but tiny amounts.
If the attacker knows the ciphertext and can correctly guess parts of the message (e.g. he knows it's a Windows executable, and therefore must start with MZ) he can get the corresponding key bits for the known range. These bits are useless for decrypting other parts of the message, but can reveal patterns in the key if it's poorly generated.
You must be able to distribute the key, and your key must be equally as long as your message. If you can keep your key 100% secret between those of you who are authorised to read the message, why not just keep your message 100% secret instead?

The weak link here is your random number generator. The security of the one time pad is entirely limited by the security of your generator. Since a perfect generator is almost impossible, a perfect one-time pad is almost impossible too.

The final problem is that the key can only be used once. If you use it for two different messages, and the attacker knows both ciphertexts, he can xor them together to get the xor of the two plaintexts. This leaks all sorts of information (e.g. which bits are equal) and completely breaks the cipher.

So, in conclusion, in a perfect one-time pad you need to know the ciphertext and key in order to decrypt it, but perfect one-time pads are almost impossible.


Are the SSL Digital Security Certificates based on Kerberos Network Security Protocol

No they are very different in the most basic sense.  Kerberos uses tokens for authentication built using a symmetric cipher.  SSL allows you to pass secret data between two machines and uses asymmetric cryptography for authentication.  It is possible to use kerberos and ssl together,  but it is less common.