How long a lifetime of a DTLS session with an IoT device should be?

There are in fact two different questions here.

Q: Do i have to reinitialize a handshake for every PUB/SUB packet i want to send through a client?

A: No.

A DTLS handshake is very expensive, so preserving/resuming the same session for every subsequent pub/sub interaction seems like a very good idea, especially given a constrained environment (which is assumed to be in place somewhere for all of the MQTT-SN usage scenarios outlined in the section 3 of the spec).

In fact, RFC 7925 "TLS/DTLS Profiles for the Internet of Things", Section 7 "Session Resumption" strongly suggests exactly that.

Note that if your environment is not constrained in any way and doesn't have anything to do with the Internet of Things at all, you would want to consider replacing MQTT-SN with something else.

Q: Can I use a session created once for indefinite period of time?

A: Sort of yes, but depends on the period.

A DTLS session does not age given appropriate session ciphers, if this is the question. However, after a certain period of time you may still want to drop it and initialize a new one through a new handshake.

A simple example of when it makes sense to do so is when on January, 1st, you connect to a server with a TLS certificate valid till March, 1st. At the end of February you may want to re-check if the remote endpoint still operates the server name you're connecting to by requesting another handshake and checking if the certificate had been updated.

Depending on how the remote endpoint authentication (both for publishers and subscribers) is designed in your case (e.g. physical security tokens), there could be different restrictions that you may want to impose.


What password cracking software is commonly used?

John the Ripper is the traditional, free, open-source password cracker (there is also a closed-source commercial "pro" version). It has been widely used for (much) more than the last 10 years.


A clean up of your code

This is the same as what you are doing, but written a bit more elegantly:

function random_str()
{
    $secret = '';
    while(strlen($secret) >= 20) {
       $str = bin2hex(random_bytes(10));
       $str = preg_replace('/[aeiouAEIOU]|\W+/', '', sha1(microtime() . mt_rand() . $str));
       $secret .= $str;
    }
    return substr($secret, 0, 20);
}

Notice I have removed the unnecesary $i variable. (I know, not a security issue, but anyway.)

Is it safe?

The code is very convoluted, and takes a rather odd path to solve a not so hard problem. Some issues:

You use the hash sha1(microtime() . mt_rand() . $str) when just relying on $str would be enough. Thats where you get the input from a CSPRNG. Adding some non secure randomness (mt_rand) and the time and then hashing it does not improve it.
Since you remove vowels from a hex string you end up only using the character 0123456789bcdf. Thats just fourteen - not a lot.
It is a bit strange to first generate a string containing characters you don't want and then throw them away, when you could just only generate the ones you want.

In the end, the result is cryptoghraphically secure, since it relies on random_bytes(), that is a CSPRNG. But the quirks of your code and your lack of understanding of it leads to insecurity, e.g. in this case you might end up with less entropy per character than what you would have expected.

A better way to do it

Use the PHP funciton random_int to pick a character from a fixed alphabet at random:

function random_string($length, $alphabet) {
    $result = ''; //Initialize an empty string.
    $max = strlen($alphabet) - 1; //The maximum random number we want to generate.
    for($i = 0; $i < $length; $i++) { //Do once for every character in the string.
        $result .= $alphabet[random_int(0, $max)]; //Add a random letter from the alphabet.
    }
    return $result;
}

The performance could probably be improved by eliminating the string concatenation in the loop, but it is probably not a big issue.


I am not a big fan of the cookie authentication as you had outlined.

Session authentication assigns a random token to the client that has no meaning other than being a pointer to the session information stored on the server. The primary problems being low entropy for token generation.

However, cookie authentication tends to have more issues. Because the information in the cookie carries sensitive data with it, it must have some sort of HMAC solution with it to prevent tampering. Ruby on Rails does this, and they've had cryptography issues and code execution issues. Play framework does this, and they've had cryptography issues and code execution issues. Such a mechanism can work when done right, but in these two examples, getting it wrong can be disastrous.


How to tell if Firefox Home (iOS) is using Data Protection API?

Look for uses of the file protection API, for example the file protection classes and constants.

See for example http://developer.apple.com/library/ios/#documentation/Cocoa/Reference/Foundation/Classes/NSFileManager_Class/Reference/Reference.html%23//apple_ref/c/data/NSFileProtectionKey

If it uses keychains it should also be using the keychain protection options.

Generally speaking you'd expect telltale constants and methods such as the following (not exhaustive) to appear in the code if it is aware of the new data protection APIs:

NSDataWritingFileProtectionNone
NSFileProtectionKey
NSFileProtectionComplete
NSFileProtectionNone

And it should be responding to lock / unlock events, i.e. should implement:

-applicationProtectedDataDidBecomeAvailable:
-applicationProtectedDataWillBecomeUnavailable:


There is no sure way to detect proxy/vpn usage. Aside from what you've done (which won't catch many users tbh), the biggest bang for your buck will be an IP blacklist (which is most likely how maxmind are detecting proxies).

Here are some sites that offer IP blacklisting (I have no experience with any of them):

http://www.shroomery.org/ythan/proxyblock.php (free)
http://www.projecthoneypot.org/?rf=41535 (free, but more general abuse protextion than proxying)
http://www.maxmind.com/en/home
http://threatmetrix.com/

There are other tricks you can do to attempt to detect web proxies (like google translate, etc), which sometimes add extra headers. The problem is you'd have to add special cases for all of the ones that do (and most don't in any case).


Is it better to hash n*x times in sha1 or n times in sha512 on the client side?

This sounds a bit stretched, maybe counter-productive, sub-optimal and it doesn't really offer much added security. The "password" is actually seen in plaintext, because the password is the string you finally send in the place of the real password. What exactly are you trying to achieve?

In any way, if you are really trying to have the 'real' password 'not being seen in clear text' (and don't trust ssl) you should be looking at implementing a challenge-response protocol.
This is usually the way one goes about if he does not want the password to be transported in the clear (or something resembling the password as in your case).

Now if you really want to go on with your plan, and still do that client-side trickery you describe, SHA-1 is perfectly fine for that. Even MD5 is fine and considerably faster. The 'talk on the street' about those functions not being secure is about collisions - which is something you probably don't care in your implementation. Also you can have a look at http://www.jcryption.org/ , it's a jquery library that does asymmetric encryption of html forms.

But, again, I strongly advise against this whole implementation.


What on earth is this log entry in Apache?

Probably someone trying to create an account on your forum and proceed to spam it.

I read about it here: http://www.projecthoneypot.org/ip_95.168.162.43

When you URL decode the string two times and google the string you find a lot of spam on different forums.

URL Decoded one time:

èñïîëüçîâàí íèêíåéì "immultusa"; çàðåãèñòðèðîâàëèñü (âêëþ÷åí ðåæèì òîëüêî ðåãèñòðàöèè);
failed, referer: http://xxxxxx.org/forums
/index.php++++++++++++++++++++++++++++++++Result:+%e8%f1%ef%ee%eb%fc%e7%ee%e2%e0%ed+%ed
%e8%ea%ed%e5%e9%ec+%22immultusa%22%3b+%e7%e0%f0%e5%e3%e8%f1%f2%f0%e8%f0%ee%e2%e0%eb%e8
%f1%fc+(%e2%ea%eb%fe%f7%e5%ed+%f0%e5%e6%e8%ec+%f2%ee%eb%fc%ea%ee+%f0%e5%e3%e8%f1%f2
%f0%e0%f6%e8%e8)%3b

URL Decoded twice:

èñïîëüçîâàí íèêíåéì "immultusa"; çàðåãèñòðèðîâàëèñü (âêëþ÷åí ðåæèì òîëüêî ðåãèñòðàöèè);
failed, referer: http://xxxxxx.org/forums/index.php
Result: èñïîëüçîâàí íèêíåéì "immultusa"; çàðåãèñòðèðîâàëèñü (âêëþ÷åí ðåæèì òîëüêî
ðåãèñòðàöèè);


Unencrypted connections between 2 people who use the same ISP, what's the risk?

What do both parties use their computers for? If either machine is infected then it really doesn't matter if you live next door to each other or in separate continents. End points are leaky little beasts.

To be more specific, You need to share how the communications are taking place. Are you using Skype or some other IM program? Email? VoIP? Because some communications programs have encryption built in your communications Some content is transmitted and received more privately than others. Do you both use a VPN?

The next question is what is the cost of the content if it is discovered? If it has no value to either party, or cost to either party if it is revealed then you are pretty secure.

Security is about managing risk. If you're talking about valuable IP, etc. then you are pretty insecure if the communications application is not encrypted properly.

Ultimately the security/privacy is limited by the weakest link, typically the end point, which includes the user as well.


Transparently authenticating users or devices on mobile devices

EAP-TLS is "just" plain SSL/TLS forced into the EAP format. EAP is an "authentication framework": a generic protocol for exchanging messages between two parties, in a question-response dialogue (the parties are usually designated as "client" and "server", whether this maps to the corresponding network concepts or not). TLS is nominally performed over a bidirectional channel for arbitrary bytes, both parties being able to talk simultaneously; however, the TLS "handshake", in which the tricky crypto occurs, is synchronous: at any point, only one party (client or server) talks, and both know who is supposed to speak next. Therefore, it is possible to split the TLS records into big packets which will be wrapped into EAP messages; that's exactly what EAP-TLS is about.

EAP-TLS achieves client authentication "by itself" when TLS certificate-based client authentication is employed: the client owns an asymmetric private key, and the corresponding public key is wrapped in an X.509 certificate, which the client shows to the server when the server asks for it. This kind of authentication works only when the client indeed contains a private key and can use it, so that's for devices, not humans (even if considering smart cards, the authentication will convince the server that the smart card is at the other end, and the server merely infers the involvement of the human owner of the smart card, under the assumption that the smart card would not do anything without the PIN code that only the human owner knows -- but the server does not see that PIN code and cannot be sure that it even exists at all).

So no biometrics for plain EAP-TLS. However, there is another mode of EAP-TLS in which no client certificate is requested; but then, EAP-TLS is just a transport mechanism, for another authentication mechanism which will be played within the TLS tunnel. In that case, EAP-TLS is just an additional network layer (a good one, since it allows for safely sending plaintext passwords, but a layer nonetheless). Note that PEAP is just the reverse: EAP inside a TLS tunnel. EAP-TLS-for-transport and PEAP are functionally similar, but correspond to distinct contexts (PEAP is there to get EAP messages when the context is a bidirectional tunnel for bytes; EAP-TLS is there to get a bidirectional tunnel for bytes when the context is a transport mechanism for EAP messages).

Speaking of biometrics, one must remember that this is about measuring things on a human body, not about secret data. Your fingerprints are not secret; you leave them just about everywhere and they can be recovered by low-tech attackers. The value in fingerprints is that nobody can have the same as yours attached to their fingers. This provides authentication, but only insofar as there is some mechanism which ensures that a real finger is placed on a real scanner. Otherwise, an attacker could just send a synthetic data packet over the network, claiming to be from a scanner, and containing a picture of your finger. The same applies to face recognition. Simply put, biometrics work well only in the presence of an armed guard (the guard does not perform the authentication, but makes sure that only true biological fingers/faces/eyes are put in front of the detector).

So what does this mean for your situation ? Mostly that EAP-TLS, PEAP... are not the relevant point. What you want is to authenticate both human users and machines, and you will need two distinct authentication methods.

For humans, you will need to map on that which works on humans, mostly passwords and biometrics. As explained above, biometrics really work only in restrictive contexts (many people use them in other contexts, but all they get is a warm feeling of security, not actual security). So this brings us back to passwords. Or you could say that humans are actually devices, with the smart card arrangement, or something similar (like a car key with the "unlock" button): the authentication is really for a device, that is assumed to be under exclusive control of a specific human user.

For machines, authentication can use a "machine password" (it is like a normal password, except that a machine will have no problem remembering a 25-letter sequence of random characters, so that's substantially easier than passwords for humans). Or it can rely on asymmetric cryptography (private key and certificate, see above).

Either way, you will probably want to know sufficiently early whether the client is a human or a device, so that the appropriate authentication mechanism may be used. And there is something just for that in EAP: the initial message from the server will be of type Identity, and can be described as the question: "halt ! who goes there ?". It is then up to you to give "names" to both human users and devices, so that the server can quickly determine whether the client is a human or a device, e.g. based on the name format. The server, in EAP, is free to select the actual authentication method after having seen the Identity Response from the client.


What do Paypal protected buttons defend against?

Protected payment button encrypts the payment amount and item details, in such way that your users won't be able to pay for that item but with different payment amount. When using regular pay button, as a vendor you have to check that the amount paid matches your own price list for the item before processing the order, this is because your user can change the payment amount.


What data is not encrypted in iOS 8+ when "locked"

By default, most data is protected using the AfterFirstUnlock class key, which certainly would be present on the device; but that's not what you're asking. You want to know what data is accessible, which is a different kettle of fish. In order to access the data, you either have to get the OS give it to you (by finding a lock screen bypass bug; not unheard of) or exfiltrate the class key from device memory somehow. That last bit is hard.

There are many exploits over the years that can give kernel-level code execution on an iOS device, but almost all of them require either unlocked physical access to the device or rebooting, which would clear the AfterFirstUnlock key from memory. The key is not encrypted in RAM, so opening the phone and accessing the RAM chip directly might work, except for the fact that the iPhone uses a package-on-package construction, and the RAM chip would have to be separated physically from the processor first--without destroying the data, so the chip would need power and/or to be frozen the whole time. The NSA might be able to pull this off, but it would take some seriously specialized equipment, and they'd only get one shot.

The USB interface offers many possibilities, as it carries IP traffic (yep, that's IP over USB) to potentially vulnerable applications. However, in iOS8 it's locked until you press "Trust this computer." If the attacker could steal the escrow keybag this creates off your already-trusted local computer, they could attack this way, but they's still need one exploit in a daemon to get code execution, another to break the sandbox, another to elevate to root, and another to patch the kernel.

Jailbreaks are much easier than this, because they can assume the user will help. That means they can use a trusted computer, and they can turn a file placement exploit into a code execution one by having the user tap an icon on their home screen.

Without user cooperation, your best bet is probably the network interface; you'll still require several exploits chained together, and you'll have to steal the password to your router to get the phone to autoconnect to the attacker's network, and then hope you don't have an always-on VPN set up.

Basically, iPhones are very secure. It's a matter of degrees, sure, but I'd still put your locked phone above almost anything but a smart card.

Edit: Source: mainly "iPhone Data Protection In Depth" by Bedrún and Sigwald, but I used to work on iOS security for the DoD. That's not to say we had special knowledge or anything (I wish, to Apple the DoD is a drop in the bucket), but I've certainly spent enough time probing the depths of the Data Protection system!

Edit 2: The biggest vulnerability in this whole system used to be the escrow keybag, which is created when you plug in to a computer and hit "Trust." This contains all the class keys you need to decrypt the phone's data, because iTunes needs to be able to back up the phone. The escrow keybag is encrypted with a random token stored on the phone, so it's normally only useful when transmitted back to the phone, but if you could just exploit something that would let you read that token back from the filesystem, you'd be in business. That said, in the 5S and later, the processor comes with a "secure enclave" that's more-or-less a smartcard built into the chip, which has its own keys. The escrow keybag's decryption key is now stored in an encrypted format, and only the secure element can decrypt it, so this avenue of exploitation has been closed.


Are there any architectures currently out there that use hardware-enforced process isolation? What would it take to add that to x86?

Actually, almost all of the CPU on the market, save for the very small ones meant for low-power embedded devices, offer "hardware-enforced isolation". This is called a MMU. Synthetically, the MMU splits the address space into individual pages (typically 4 or 8 kB each; it depends on the CPU architecture and version), and whenever some piece of code accesses a page, the MMU enforces access rights, and also maps the access to a physical address (or not -- this is how "virtual memory" works). At any time, the CPU informs the MMU whether the current code is "user code" or "kernel code", and the MMU uses that information to know whether the access shall be granted or not.

The access rights and mapping to physical addresses of each page is configured in special tables in memory, that the kernel shows to the MMU (basically by writing the start address in physical RAM of the main table in a dedicated register). By switching the MMU configuration, the kernel implements the notion of process: each process has its own address space, and when the kernel decides that the CPU shall be granted to a process, it does so by making the MMU configuration for that process the active configuration.

This is about as hardware-enforced as these things can get. If you wanted a software-only isolation enforcement, then you would have to look at things like Java or C#/.NET: strong typing, array bounds check and garbage collection allow for cohabitation of distinct pieces of code with isolation and without the help of a MMU.

MMU-based process isolation works well in practice -- processes cannot alter or even see the pages of other processes. The last major operating systems where this was not done properly were the Windows-95 family (up to and including the infamous Windows Millenium Edition, in 2001).

The trouble begins when you begin to understand that complete isolation is useless: application processes must, at some point, be able to interact with the hardware, to save files or send data over the network or display images. Therefore, there must be some specific gateways that allow some data to flow in and out of the isolated address space of each process, under strict control of an arbitration system that maintains coherence and allocation of hardware resources to process; that arbitration system is exactly what is known as an "Operating System". The "gateways" for escaping isolation are often called system calls.

Right now, the OS is software, and has bugs, because every significant piece of software has bugs. Some of these allow for maliciously written process to impact other process in bad ways; this is known as "security holes". However, making a "fully hardware OS" would not solve anything; in fact, it would probably makes things worse. Hardware has bugs too; and the source of bugs is that what the developer is trying to do is complex. Doing it in hardware only makes bug-fixing a lot harder, so it does not improve the security situation at all.

Thus, to make a better isolation between process, the solution is not to throw more hardware at the problem. There is already enough of the stuff (and maybe too much). What is needed is a reduction in complexity, which really is a thorough pruning and redesign of the list of system calls. A basic Linux kernel offers more than 300 different system calls ! This makes for a lot of work when trying to prevent security holes. Unfortunately, removing system calls breaks compatibility with existing code.


Broadcast deauth requests are not working

If you are after just any user on that network, you can use airodump-ng on a specific BSSID. For example, running the command airodump-ng wlan0mon --bssid 00:00:00:00:00:AA --channel 1. Here is a sample output of the command:

 CH  1 ][ Elapsed: 10 s ][ 2016-12-31 12:00

 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID

 00:00:00:00:00:AA  -59  93      112      698   69   1  54e  WPA2 CCMP   PSK  Network

 BSSID              STATION            PWR   Rate    Lost    Frames  Probe

 00:00:00:00:00:AA  00:00:00:00:00:AB  -37    0e- 0e     0      696
 00:00:00:00:00:AA  00:00:00:00:00:AC  -47    0 - 1      0       24
 00:00:00:00:00:AA  00:00:00:00:00:AD  -66    0 - 1      0       52

As you can see, running the above command outputs the BSSID, as well as the devices connected to the BSSID (00:00:00:00:00:AB, 00:00:00:00:00:AC, and 00:00:00:00:00:AD). Now you can use the command aireplay-ng --deauth 0 -a 00:00:00:00:00:AA -c 00:00:00:00:00:AB wlan0mon to deauthenticate the specific client.

Make sure to subsitute this example with your own WiFi card, BSSID MAC address, and channel number. The BSSID and channel you're after can be found by using airodump-ng wlan0mon, again using your WiFi card.


How Involved Should a Developer Be in Designing a Security Policy?

I'm also a developer, and my passion for security often makes the dynamic a little unusual when dealing with other non-security-focused developers.

There are three main areas of constraint when it comes to security policy:

Usability: Making sure that the user can actually use the software, and that they don't get overly irritated or delayed by security measures.
Technical: Making sure than security mechanisms are properly implemented, and that they don't affect uptime, maintainability, or other critical technical factors.
Financial: Making sure that the security measures don't cost too much, whether it be through direct financial costs (e.g. buying black boxes with blinky lights) or additional man-hours.

Your job should involve advising on the technical factors, and suggesting ways that you might mitigate any usability impacts. However, you should almost always defer to the technical judgement of a competent security consultant (competent being the operative word) if they disagree with you on a technical security matter. It's your job to integrate the necessities into a product in an optimal fashion, whilst overcoming the difficult hurdles.

In terms of direct involvement in security policy for software development, it largely depends on:

Whether you have a dedicated security person or team.
What sector you work in (means you might need to deal with PII or HIPAA data)
Where you are in the organisation, and whether you're in a position to effect change.
How security-focused the company is.

The interesting part of this question comes when you consider that most software organisations don't have a dedicated security person, let alone department. Regardless of whether or not your company does, you have a duty to learn about the types of security issues and mechanisms that apply to your work. If your company doesn't have a "security guy", that responsibility is even greater. Part of your job is to implement working and reliable software, which includes security, but another part involves relaying technical information to management in a way that they can understand. You can't do that effectively unless you understand the issues at hand.

In short, there's no simple answer. You're required to make some security decisions and implement certain mechanisms as part of your job, because that's what a developer does. As for how far you go, it entirely depends on you as a person and the organisation you work in. In order to make reasonable judgements when no overriding directive is provided, you need to put in the work to understand the issues.


Why was running OpenSSL dhparam too fast?

When creating Diffie Hellman parameters it takes the most time to create the modulo p, which is a big prime number. To create this, a semi-random number is taken and checked for primality. If you are lucky and you pick a prime number soon, the algorithm finishes quickly.

Specifically:

BN_generate_prime_ex calls probable_prime_dh_safe that takes a random number and checks whether it is divisable by the first 2048 primes. If it is, it takes another random number, etc. If it finds a likely prime, it prints a dot.
It calls BN_is_prime_fasttest_ex, which does the Miller–Rabin primality test. It prints a '+' if the tested value is prime.
It tests both p and (p-1)/2 this way, and prints a * if both are prime. It tests it a couple of times to be really sure. For 2048 bits, it checks it twice. That is why you see ++*++* on the end of the output.

It repeats these steps until it finds a number that is very likely to be prime. How many loops are necessary depends on chance.

Openssl docs


Can I determine which algorithm was used if I know the matching hash of a given input?

On observation this looks like base64 encoding (note this isn't a hash, it's an encoded string). I can tell this as I know that in base64, one pads the end of the string with = as necessary to give the base64 string a predictable length. Other tell-tale signs can be from the usage of certain characters in the string. These you will learn by simply exposing yourself to existing examples and reading about the various encoding algorithms out there.

The base64 encoded string of 12345 is actually MTIzNDU=, not what you provided. Decoding your supplied string yields: NëtžQEgÛVÄç5•. The high entropy here indicates this is probably the result of some encryption algorithm. Since the point of a good encryption algorithm is the inability to determine it from random data, it is not often simple to discover which algorithm was used and you would normally have to resort to brute-force efforts.

Assuming this is some kind of exercise where you are certain your input resolves to this and you've been asked to determine the password used to encrypt it, you can brute-force using a method which after trying a password checks to see if the output is indeed 12345. This way you can actually verify you have guessed the right password. Good luck!


Signing my certificate by using my smart card and eID card?

Your eID uses an X509 certificate signed by a CA controlled by your government. That CA is the root of your trust chain. This means that they are the one guaranteeing that they issued that certificate to you as an individual.

Signing your own public key would not provide any additional information since it's in the same trust chain.

It can even be dangerous: for instance, if you generate a PGP key and sign the public key with your personal certificate, it fails to prove that you have any access to the private part of the same key. All it proves is that, at some point, you (and you alone) claimed to own the corresponding private key. It is roughly similar to signing a photocopy of a passport: it doesn't tell the recipient that the document is an original or that you have any access to it, just that you claimed to have it and, without a trusted 3rd party authenticating that claim in a different way, it's useless.


Physical computer security, how to disable USB ports when the computer is 'locked'?

The standard approach is to fill the USB ports with epoxy resin. Of course, this must be combined with similar approaches to seal the case, so the attacker can't get in via the PCI bus, etc.
Note that even if you do this, law 3 still applies: if a bad guy has unrestricted physical access to your computer, it's not your computer anymore.
EDIT: reflecting update to question:
In the specific scenario you outline, then to block it, just turn off auto-run. It should already be off in Windows if you've got it patched properly; in Linux how to turn it off (or even if it's on) depends on Distro, Desktop Environment, etc.
However, please do note that the specific scenario you outline does not make sense. If the attacker is serious enough to build a custom USB stick to do this, then they are not going to be so casual that they give up when it doesn't work, and will try something else. Boot from a LiveCD, copy your TrueCrypt volumes, install a keylogger, and wait to get the password in the mail, for example. Law 3: it's their computer now.
Actually an attacker serious enough to build such a stick probably isn't going to bother because they'll not expect auto-run to still be on.


Constructing a tainted string for arc injection

There are two things you should consider in this piece of code:
The first one is the type of the variable pwStatus, the second one is the value of the strcmp return address.
The goal is to overwrite the strcmp return address to make the pwStatus variable to be always true, because of pwStatus variable could only be true or false; So, if the ASCII code of one character of the string buffer passed to the strcmp function overwrites the pwStatus variable to a true value, the flaw of the script code is managed to grant you the access.
If the password is only 8 char, why don't you use strncmp instead of strcmp on a 12 or more char buffer ?


Can I scratch off the magnetic strip off a debit card to only allow chip and PIN?

As Phil stated, you can still use the card using its number (as you would do on-line).
Also, some ATM machine won't accept the card if not able to read the magnetic strip.

The best thing is to use a credit card: in that case you can block the payment and get a refund.


How safe is the VirtualBox NAT network adapter option?

The very purpose of virtual machines is to isolate the guest OS from the host OS, therefor the situation you're suggestion should not happen under normal operation.

To think of it another way, if you download a virus, the traffic passes through your router. Does your router get infected? Of course not. The same principle goes for your host NATing traffic for your vm.

It is possible that a bug in the virtualization software or your host's network stack could allow a sophisticated attack to "break" out of the vm.


If I login using browser X, will CSRF work in browser Y?

No.  CSRF works by using a session already in place, and sessions can only exist within the same browser.  Or put another way, all current/major browsers do not share sessions.

EDIT: As noted in the comment, it is theoretically possible using flash cookies.  IMO, flash cookies are evil to begin with though.


Cloudflare cipher selection based on AES-NI support

During the TLS handshake the client sends the ciphers it supports in the order of preference. This way a client can signal that it would prefer ChaCha instead of AES ciphers since ChaCha is less resource intensive than AES when implemented in software only. The server can adhere to the clients preference when choosing the cipher and thus select ChaCha instead of AES.


Is accessing carelessly not protected data of any service unlawfull?

(Speaking from 5 years old info gotten by searching internet piracy laws)

In France, the laws state that unauthorised access is illegal, and more interestingly maintaining unauthorized access is as much illegal as getting it.

Analysis of those laws, in French

I am not aware of the rest of the world's laws, but it seems it is indeed unlawful, as it is trivial to show these data were not intended for your use, making your access unauthorized thus illegal (however well intentioned you might be)

The fact that it is a bug / error that you exploit might be used against you rather than being in your favour, I can't imagine any case where it might be otherwise (since any intrusion is based on bug/error / edge case of security policy)


Which encryption algo should be best for an Android application

It depends on what attacks you're worried about.

In general, I'd advise against creating your own scheme even if it uses accepted algorithms. Your case sounds like it is easily served with standard SSL, perhaps with client-side certificates as well as server-side.

If you go and use an encryption algorithn directly, without some widely accepted scheme around it, you're opening up to a whole range of attacks that you can't possibly think of all by yourself.

For instance, say you would just encrypt the string and transmit it over HTTP. An eavesdropper would not be able to decrypt it, but could save it and re-send it at a later time. Also, any scheme that doesn't introduce a freshness property, such as timestamp or nonce, will be susceptible to statistical attacks on those strings, especially if they contain text in a known language.

If there is no reason why normal SSL, perhaps coupled with authentication in the application, would work, the stick to that.


When using HTTPS, which part of domain is revealed to ISP?

I think you are referring to the hostname as given in clear text in the SNI extension in the ClientHello message as part of the TLS handshake. Since this extension is used to tell the server what certificate to provide as part of the TLS handshake and the server might have different certificates for different subdomains, the SNI extension must contain the full hostname like foo.bar.example.org and not only part of it like example.org.


The sad truth is that tightening your network will make you unpopular at your workplace. That said, many sys-admins would rather be unpopular knowing they have a safe(r) network than popular and spending all their time cleaning malware.

Some cheap and effective ways to eradicate malware

take away local admin, like you're planning to do (I can't stress this enough)
Update web browsers / Flash / Java / PDF Software via GPO and WSUS. Web browsers and PDF's are two big targets for malware.
You could run No Script to avoid drive-by downloads if you wanted to
Update your machines with WSUS (like you're currently doing)
Block .exe / .bat / .vbs / .sh attachment file extensions from entering via e-mail
Beef up your anti-spam on your mail server (if applicable - vamsoft ORF is a great MS Exchange anti-spam that costs about $160 USD)
EDUCATE YOUR USERS - Conduct a few lunch and learns and let your users know what a suspicious e-mail looks like, that they shouldn't click links in e-mails from recipients they don't know, safe web browsing practices, etc
Block any outgoing traffic on port 25 from every machine in your network except your mail server(s). This will prevent you from getting blacklisted.
Stay up-to-date on malware and read RSS feeds to read up on malware. Stay pro-active and block outgoing traffic on any known ports used by malware in an attempt to block infected computers with communicating with C&C machines.

I hope these tips help. It's important to note that you'll inevitably get some malware that slips through the cracks (zero days are a bugger), but you'll find that good practice can go a long way toward keeping a clean network.


Is it possible to get all the data I send through wifi?

On any Wi-Fi network - encrypted or not, given today's Wi-Fi encryption protocols - any sufficiently skilled and equipped user of the network (and especially the network administrator) could easily access any data you transmit or receive via cleartext protocols.  This includes usernames and passwords as well as web pages, documents, and other data sent or obtained via http, ftp, telnet, etc.

For open networks, gathering cleartext data is as easy as sniffing the traffic in the air.  WEP security adds a slight barrier, but is still easily decipherable by even unauthenticated users.

WPA and WPA2 require a good bit more computational power for outsiders to crack, and much more time.  For these, an attacker would most likely monitor traffic for awhile and then take the data home for offline cracking.  As with just about any cryptography, brute force will always win if given enough time.  With WPA and WPA2, that just means a lot of time.

There are side-channel attacks to WPA and WPA2 though.  Currently, the Wi-Fi Protected Setup (or similar) features in most SOHO routers has a weakness that will allow an attacker to gain access to your network in fairly short time.  Once they've cracked your key through this method, they can join the network like any other user (provided you don't have other protections - most of which are trivially bypassable - in place).

For WPA and WPA2, there are known weaknesses that allow authenticated users (or attackers who have broken into the network) to sniff traffic as if it were unprotected.  At this point, the only defense you have is encryption at higher levels of the network stack (i.e.: HTTPS).  Even then, many of these higher-level protocols can be subjected to man-in-the-middle (MitM) attacks if the victim is less than vigilant in verifying their SSL certificates (or the attacker has a certificate from a compromised CA).

The only real additional threat that a malicious network administrator would pose, is that they have access to the wired side of the network also.  On the wire, traffic is not protected by the same encryption (WEP/WPA/WPA2) that applies to the wireless connection.  Anyone on the wire could then sniff your traffic as if it had been sent across an open (unprotected) network on the air.


Message authentication code based on a single AES block

If you really need to use AES, then you may use CBC-MAC. Be wary, though, of the conditions: CBC-MAC is secure only if:

all messages have the same length, or (alternatively) you always compute the MAC over a structure which begins with a header which defines the message length;
you never use the key for anything else than CBC-MAC (and, in particular, you don't encrypt anything with the same key).

If you are already ready to use a hash function, then you will find it simpler to rely on HMAC. HMAC uses only a hash function, not a block cipher, so it is less complex than combining a block cipher and a hash function. HMAC is already implemented in many cryptographic frameworks (as usual, the less crypto code you have to write yourself, the better you get). HMAC/MD5 is, as far as we know, secure, despite the known weaknesses of MD5. However, if only for public relations, you might want to use HMAC/SHA-1 or HMAC/SHA-256. You can also truncate the HMAC output: this is known to be safe, i.e. if you truncate the output of HMAC/SHA-256 to, say, 80 bits, then you get a good 80-bit MAC, that the attacker won't be able to bypass with probability higher than 2-80 (and that's already complete overkill for most purposes).


Can I rely on openssl_random_pseudo_bytes() being very random in PHP?

open_ssl_random_pseudo_bytes is a cryptographically secure pseudo random number generator (CSPRNG).

In layman's terms, this means that it can generate an unpredictable, uniformly distributed sequence, that is suitable for key generation. The unpredictable property is important, because even if the full state of the random number generator is known, an attacker cannot recreate previously generated sequences, and it is unfeasible for an external observer to guess the state in order to predict future sequences.

This is in contrast to say a random number generator that takes its seed from the number of seconds past midnight and then generates predictable sequences based on this seed. In this case an attacker can simply set their own system to generate numbers using the same seed and can effectively guess token values in order to use them for their own nefarious purposes.

64 bytes will give you 512 bits of entropy. Since MD5 outputs hashes of 128 bits, there is no advantage of having the entropy generated being greater than 128. If the code is ran one billion times then there is a statistically probable chance of it always being unique because you have an output keyspace of 2128 (3.4 * 1038). The collision rate of MD5 is about 264 which is about 18 billion billion.


Can change flow of the program yet can't execute shellcode

The reason why it failed is because of bad shellcode, i took the one from The Shellcoders Handbook and it worked like charm.


Disable Encrypted Protocols Through Firewall

Is this a normal practice?

Well, it's more common (in my limited network security experience) to force the installation of a man-in-the-middle root cert on all clients on that network and then run a tool that uses the MitM certificate authority to decrypt and inspect TLS traffic. This doesn't work perfectly for some programs (which may use certificate pinning or have their own certificate stores) and is TLS-specific (there's an equivalent you could do for SSH, though I've never seen it done).

  (You didn't ask, but) Is it a good idea?

Honestly, if it's being done by port filtering, it's pretty trivial to bypass. There's no rule that says SSH must use port 22, or HTTPS (never mind any other TLS protocol) must use 443; those are merely the defaults. I could simply set up an external SSH server listening on another port, then SSH to it and use it as a proxy to bypass the monitoring. You can't even do this by simply whitelisting ports; so long as I don't have anything else (like a web server) running on port 80 on my machine, I could set up my SSH server to listen on that port.

It's much more effective to restrict connections - especially outbound ones - in general. Only allow them with the specific combinations of addresses, ports, and protocols that are required, and nothing more. If you have some specific reason that your machines need to make outbound connections to UDP port 9670 on the 233.14.98.128/25 subnet (all numbers sourced rectally), you can allow exactly those connections and no others.


I don't know if this is the best channel to ask, however - this is how I do it.

Simple information:

openssl s_client -state -nbio -connect myhost:443

If you need a deeper insight, you may want to create a Java application (this part you may not like if you're not from Java world) which connects to the SSL socket and start it with the following parameter: -Djavax.net.debug=ssl

This will print / debug the SSL hasdshake and SSL related events. If you want to print out all network events, you can use the all value.


Assume that the attacker ... can analyze the traffic

Based on this I would assume that the attacker can see the traffic. It can thus see the packets send by the client Ci. It can generate a new message with the same and IPi (using IP spoofing), IPS, and X as a previous one but with a large L. Since the authentication of the client is only based on a static token X which is the same for all messages from Ci and independent of the actual number of requested bytes, this request will be considered a valid request from Ci. This small request will trigger the sending a huge amount of random data from IPS to IPi - thus causing a denial of service against Ci.


How to prevent an arp poisoning attack (from the client's POV)

That is possible by defining static ARP entries for local IP's you are connected with, on Windows machine you could define static ARP entry using netsh .

EX:
netsh interface ipv4 add neighbors "Local Area Connection" 10.1.1.1 12-34-56-78-9a-bc


Outbound DDOS attack from a centos server

The first port of call might be to take a packet dump (ie, tcpdump)  and see what it is you're throwing out.


How should I manage people/technicians during an incident/outbreak?

Plan your business continuity. You should identify the proper people for mission critical and non-mission critical services, which systems contain the most important information, who can decide when to take the systems offline and at what threshold.

Good overview on (wikipedia)[http://en.wikipedia.org/wiki/Incident_management]

ITIL has tons of information on this:

Activities of ICM defined by ITIL v3

Identification - detect or reported the incident Registration - the
incident is registered in an ICM System
Categorization - the incident
is categorized by priority, SLA etc. attributes defined above
Prioritization - the incident is prioritized for better utilization
of the resources and the Support Staff time
Diagnosis - reveal the
full symptom of the incident
Escalation - should the Support Staff
need support from other organizational units
Investigation and
diagnosis - if no existing solution from the past could be found the
incident is investigated and root cause found
Resolution and recovery - once the solution is found the incident is resolved
Incident closure - the registry entry of the incident in the ICM System is
closed by providing the end-status of the incident[5]

Incident Manager responsibilities

understand any incident/fault on a basic level (at least) in order to use the appropriate competences (resources)
drive the restoration team to gather sufficient
information to start an analysis maintain a general overview of the
incident (keeping the focus on the restoration via a workaround)
understand the functionality of multiple areas (RAN, Core Network,
VAS, BSS/OSS)
obtain guidance on priorities to the teams starting the
immediate urgent unexpected recovery work


Determining safety of Android APK executable that requires root

You mention that the developer sells a public version of this application you were given. If you trust the public application then you can use androguard(androsim & androdiff) to figure out the similarity % between your new version and the public version.

If say, they are 95% similar then you only have 5% of the code to inspect. Then you can even see what specifically is different between the two apps and decide for yourself if the new code is malicious and if you'd like to use that app.


Can I be reasonably certain that IRS website is genuine?

If you Google the IRS you will see:

irs.gov is the top hit
irs.gov is in the Google info box on the side
wikipedia lists irs.gov as the official website
Twitter lists the official, verified IRS account as having irs.gov as the homepage

In addition:

.gov websites are not available to the public
The official government page for America lists irs.gov as the official website


Why would fraudsters use old user-agents (old browsers versions)?

My guess is that the traffic you're seeing is not actually coming from real browsers, but from some sort of automated web crawler. Remember that if you're writing your own program, then useragent is just a string and you can set it to whatever you want -- usually whatever's current at the time you write the software. I'm guessing that either the crawlers don't get updated very often, or the developers of the crawlers don't bother updating the useragent strings.

That would also explain seeing multiple useragents in the same conversion if different parts of the web crawler are hard-coded to send different useragents.

I wonder if you could turn this into some way to differentiate real human clicks ...


Can National Insurance number and Unique Taxpayer Reference be stored unencrypted in a database?

Legalities aside, you should always be very careful about how you store personal data. Details like NI number can be used to impersonate individuals (particularly where it stored alongside other identifying information such as names or email addresses) and can lead to identity theft.

If you don't need the information, don't store it at al
If you do need it, secure it very carefully. This includes but is not limited to encryption; there is no point spending the time encrypting your database if the application that has access to it has a SQL injection vulnerability that allows someone to enumerate all of the data anyway


Actually, the answer is within your question:

  But during the handshake it can prove it holds the private key that
  matches example.com certificate

This outlines that  that the common name  in the SSL certificate doesn't match the address that is in the address bar of the browser (foo.com). I mean the warning claims that the certificate that has been picked up by request is issued for example.com, not for foo.com .

It is like foo.com is trying to intercept the communication between you and example.com, and that is the reason of the legitimate security warning you got.


The generic term for "Working out how to decrypt encrypted string when knowing the plain text" is "known plaintext attack," if you'd like to research the topic more.

Luckily for you, these examples are not exactly encrypted. They're too short for block encryption; and a good stream cipher wouldn't start with the same characters each time.  After a bit of examination, it looks like they're xor'ed with a static string which starts with "sdrsdffg"

A bitwise xor with a static string is a cheap and common way to obfuscate a plaintext; but as you can see, it's not the most secure thing in the world.

There's algorithmic ways to figure out the rest of the static string if you have longer ciphertext samples.


Longer passwords vs Password Composition Rule

Every character added to a password increases the number of possible passwords exponentially, a 16 character password has many orders of magnitude more possibilities than an 8 character password. This doesn't eliminate dictionary attacks, however it makes them much more challenging simply because there are so many more possibilities.


Unable to downgrade https to http through sslstrip, arpspoof

First of all: What sslstrip does is it replaces https-links with non-https-links on hijacked non-https- websites. E.g. when the victim visits a http-only search engine via an insecure public wifi, the attacker can use sslstrip to replace https-links in the search engine- results with http-only links.

I guess that the websites you are targeting (e.g. linkedin) always redirect to https, regardless of what the victim attempted to open. And won't allow http-connections in the first place.

And last but not least, like others already mentioned in the comments, the target websites most likely set a strict-transport-security header in the first response (or even an OPTIONS response, which can be easily overlooked), which will prevent the browser from allowing http-only connections.


Do all hard drives support Device Configuration Overlay (DCO) and Host Protected Area (HPA) for data sanitization?

I learned that often the best way to sanitize a drive is to use the software tools or guidance provided by the manufacturer. If such a tool is not available, then try hdparm.

sudo hdparm -N /dev/sdX to check whether HPA is enabled or disabled.
sudo hdparm -g /dev/sdX to check number of sectors.
sudo hdparm -Np<MAX SECTORS> /dev/sdX to disable HPA.
sudo hdparm --yes-i-know-what-i-am-doing --dco-identify /dev/sdX
sudo hdparm --yes-i-know-what-i-am-doing --dco-restore /dev/sdX

Make sure the drive is connected to a SATA port directly. (Don't use a SATA-to-USB adapter.)


Are there any mechanisms to verify the correctness of a burned disc?

I assume that your ISOs a provided with a hash in order to verify their integrity right?

Just grab the hash along with the ISO, write that sucker down on a piece of paper (yes it's long, just do it).  When you've burned your DVD, pop it into another system and generate an ISO based off the DVD using the dd command (unlikely anyone would compromise dd in this particular senario).  Then just run the hash against the generated ISO to compare.

If you can't trust the hash listed with the ISO when you're grabbing it, then I suggest contacting the originator of the ISO out of band (yes, we still have phones) to get the hash.


How do some sites (e.g. online banks) only ask for specific characters from a password without storing it as plaintext?

Whilst I don't know explicitly how banks handle this requirement, an alternate process to the one that @rakhi mentions would be to use an HSM and reversible encryption.

The idea is that the full password would be stored in the database encrypted using a symmetric cipher (eg, AES).  Then when the password characters are passed to the application they are fed into the HSM along with the encrypted password.

The HSM could then decrypt the password and confirm that the 3 characters are as expected, returning a pass/fail response to the application.  So at no point is the password held in the clear (apart from in the HSM which is considered secure).

This would tie up with the way that PIN encryption can be handled by ATM networks (eg, symmetric encryption and HSMs)


What string encoding options are there besides xor?

Given that you specifically want to encode individual chars as individual chars (i.e. 8 bits converted to 8 bits), the only requirement that you have is that your encoding function is a bijection -- that is that it never maps two input characters to the same encoded character.  As long as you maintain this requirement, you can always calculate an inverse function which restores the original characters.

XOR is one such bijection.  An addition (modulo 256) is another bijection.  Swapping high and low order nybbles (4 bits) is another option.  Swapping every other bit is an option.  Any one of these will suffice.

In fact, one can trivially prove that there are precisely

  857817775342
  842654119082
  271681232625
  157781520279
  485619859655
  650377269452
  553147589377
  440291360451
  408450375885
  342336584306
  157196834693
  696475322289
  288497426025
  679637332563
  368786442675
  207626794560
  187968867971
  521143307702
  077526646451
  464709187326
  100832876325
  702818980773
  671781454170
  250523018608
  495319068138
  257481070252
  817559459476
  987034665712
  738139286205
  234756808218
  860701203611
  083152093501
  947437109101
  726968262861
  606263662435
  022840944191
  408424615936
  000000000000
  000000000000
  000000000000
  000000000000
  000000000000
  000

possible ways to encode a character this way, which is 256!.  If you exclude the possibility of encoding all characters to themselves, subtract one from this number.

XOR and addition have a particular advantage that they are almost always hardware accelerated -- CPUs can do them in one cycle, with one instruction.  This makes them fast and easy.  Some CPUs also have a "barrel shift" operator which does a shift, wrapping the bits around to the other side, so on those CPUs you could also use a shift efficiently.

XOR is the most popular for many reasons.  It's trivial to understand at a bit level, and has a convenient property that encoding and decoding are precisely the same.  It's also technically keyed.  While unsigned addition of 128 also encodes/decodes with the same instruction, only one such number works that way.

In the end, XOR is also popular because nobody really cares all that much.  If one is merely obsfucating content lightly like this, there's no real advantage to being creative.  You go with what is easy.  XOR shows up in all the examples, so XOR is what people tend to use.  Thus people tend to make examples using XOR.  With no real advantage to doing better, XOR kind of wins the day, thanks to that feedback loop.


How do application specific passwords work in Google accounts?

Google just associates that password with only that service. You could reuse that password for that account across, say, multiple email clients connecting to Gmail. But you wouldn't be able to also use that password for Youtube.

As far as password strength, they use a 16-letter random password. Simple arithmetic shows that the entropy in a random 16-letter string is a little over 75 bits (2616 is roughly equal to 275). This isn't quite strong enough to use as an encryption key, but is more than strong enough as a password, particularly if they also use a slow-hash for storage.


Blocking Windows 10 telemetry destinations with Windows Firewall

There are two competing tools that accomplish the goal of blocking Windows 10 Telemetry

Anti-Beacon by the makers of Spybot S&D
ShutUp10 by O&O Software GmbH

which to use is subjective and I will let you make your own choice.

In terms of using Windows own firewall ... unsure, but to the best of my knowledge both of these programs make use of the hosts file which seems to work just fine.  Something that you have to understand is that as much as M$ wants to spy on you ... this OS is also used by businesses and the government / military ... while im sure M$ could write a backdoor in there own firewall I suspect it would cost them more government contracts then it would gain them in analytics / advertising.


Remote Desktop Access to Local Networked Machine

All machines on an untrusted or semi-trusted network should run their own firewalls. They should also be running anti-virus and have strong pass phrases for all logins and no default ID's. You should also make sure that remote support & remote access protocols are turned off unless needed. Periodic anti-rootkit and anti-malware checks may also be helpful. In other words, all the usual stuff you would do. Laptops should also have fully encrypted drives and ideally disabled USB ports (though few people will want to live with the hassle of that).

You haven't said what OS but assuming Windows 10, it already has a reasonable, pre-configured firewall.


Summer Internships (for IT/Security/Networking?)

You may have luck selling the idea to a small company with no ITSEC department. I would sell the idea as a IT Security best practice analysis. Suggestions would be to analyze their public website for issues found in the OWASP top 10. Evaluate how their server and workstation management/policies/procedures stack up against the SANS TOP 20. Evaluate the effectiveness of their IDP/IDS if they have it; Install and configure SNORT if they don't. It would be a win-win situation.


Is it enough to have Intermediate CA certificate in Trust store to validate a server certificate?

Take a look at RFC 5280 Section 6.

  The selection of a trust anchor is a matter of policy: it could be
     the top CA in a hierarchical PKI, the CA that issued the verifier's
     own certificate(s), or any other CA in a network PKI.  The path validation procedure is the same regardless of the choice of trust
     anchor.  In addition, different applications may rely on different
     trust anchors, or may accept paths that begin with any of a set of
     trust anchors.

In other words, it depends on the implementation of the certification path validation at the client side. For some clients it works by having only a trusted intermediate CA certificate for others the full chain is required. Some client also cache the intermediate certificate once they have been verified in order to speed up the validation process.


RSA and ECC are asymmetric encryption algorithms which are considered by experts to be the types of algorithms relatively easier to break by quantum than symmetric encryption standards.
For file encryption and storage you should therefore take a better look either at AES256 or Serpent. Both are symmetric.
two Quotes by the expert Daniel Bernstein:

"In contrast to the threat quantum computing poses to current
public-key algorithms, most current symmetric cryptographic algorithms
and hash functions are considered to be relatively secure against
attacks by quantum computers."
"While the quantum Grover's algorithm does speed up attacks against
symmetric ciphers, doubling the key size can effectively block these
attacks."


When is content security policy (CSP) not appropriate?

CSP is only in effect on content that creates its own rendering context. In general, this means two kinds of content: HTML and SVG (other XML-based types, such as RSS/ATOM, might also support CSP in the few browsers that still support them; I'm not sure). These might be full pages, frames, iframes, objects, or (in the case of SVG) images. Note that it only impacts content that is rendered directly into the page; if the contents of an iframe are retrieved using XHR/Fetch and then dynamically inserted into the iframe's document, then CSP headers on the XHR/Fetch response will not have any effect (CSP in HTML meta tags will still be effective when the iframe loads).
Additionally, subcontexts inherit CSP from their parent context. This means that you don't need to set a CSP for something like an SVG or iframe if you set it for the parent page. However, it's still a good idea; if there's an XSS vuln in a subcontext (yes, SVG can contain script!), an attacker would just navigate the victim to the SVG/iframe/etc. URL directly, rather than to the parent page, and you don't want them to be able to skip CSP that way. It's also possible to extend or override the parent context CSP, which is useful in some cases (e.g. allowing inline styles in SVG but not elsewhere).
Mind you, there's no harm - aside from slightly more network traffic - in sending CSP with every response. But if you want to reduce it, HTML and SVG are the areas to focus on. Redirects and error pages with no content are probably fine to skip, but if there's any HTML content, it can use SVG. If you want to go extremely minimal for some reason, CSP can be safely skipped on any page that neither handles any user-sourced data (including stored data from the DB) nor includes any externally-sourced content (scripts, stylesheets, images, iframes, etc.). However, it's best to send CSP with such responses anyhow, as the content of those pages might change in the future and it's best to be already protected (especially at such minimal cost).


What are the security trade-offs of using reproducible builds?

Against which types of attacks will it reduce security by preventing
  compilation techniques based on randomization?

You may be thinking about a technique like Address Space Layout Randomization (ASLR).  However, ASLR is not a compilation technique; it is not created in the compiler or the linker.  ASLR is a function of the run time environment's operating system.  It is in the part of the OS that loads the code into memory at a random position every time it's loaded.

Distributed code is never random.  In some rare cases it may be unique based on watermarking or licensing schemes, but the only purpose of those techniques is for the author to enforce copy protection, licensing, or billing.  These are exactly opposed to the purpose of reproducible builds.


Security concerns with TCP holding onto out-of-order packets?

This is limited by the TCP window size.

It's not enough to just guess any number greater than the sequence number; it must be between the sequence number and (sequence number + window size).

I don't know how much easier this makes brute forcing a sequence number in practice. "Overlapping fragments" has been the cause of some historic vulnerabilities, but I believe all modern TCP stacks have good defences.


In TLS, the client announces its maximum supported version. Then the server responds with the protocol version that will actually be used for the connection.

So for instance, if a server knows TLS 1.0 and 1.1, and the client announces "I support up to TLS 1.2", the server, without knowing what TLS 1.2 may be, can still respond: "fine, we'll use 1.1".

Theoretically, if a client says "I support up to TLS 1.38" (which will be encoded in the ClientHello as two bytes of value 0x03 0x27), a server who supports up to TLS 1.2 will not have any clue of what TLS versions 1.3, 1.4... to 1.38 are (and, indeed, such versions don't exist yet, the maximum defined being TLS 1.2 right now); however, that server can still say: "1.38 is higher/later than 1.2, so the client should know about TLS 1.2" and proceed with stating: "we will use 1.2".

In practice, some servers are poorly written, and when a client says "TLS 1.3" they drop the connection. This is a server bug; but a widespread one. That bug is often designated by the expression "version intolerance". Some of these buggy servers accept some kinds of unknown versions, but not all. E.g. some servers would tolerate any "1.x" version for any x in the 0 to 254 range, but would reject a version "2.y".

Because of version intolerance, clients (Web browser) must already include contingency code which tries several times. E.g. it first try to connect with "1.2" in the ClientHello, but if the connection fails, the client tries again with "1.0" as maximum supported version. This is tiresome and kludgy. A server that does not tolerate TLS version 1.3 is a server that will be troublesome when TLS 1.3 is specified and browsers begin to use it.


Why can I see the Basic Auth credentials in plaintext when using SSL

Man-in-the-middle attacks are prevented on SSL secured channels by using host certificates signed by trusted third parties (Certificate Authorities). Burp Suite can generate certificates for arbitrary hostnames but can't have them signed. If you connect to a HTTPS site via a standard browser through Burp you will see a warning window, telling you that the identity of the remote host can not be verified. If you ignore the warning Burp will intercept and decrypt all the traffic (including headers) for you.

In your case it seems like one of the apps on your Android device accept untrusted certificates generated by Burp:

Exchange ActiveSync may simply ignore the fact that it connects to a host with forged certificate
ProxyDroid may provide an HTTP interface for ActiveSync and ignore the server certificate
ProxyDroid may have installed its own CA certificate to your device and provide an HTTPS interface for ActiveSync.

So in summary SSL can protect you from MitM attacks only if your applications actualy verify the digital certificates of the remote hosts they connect to.


Using the GUID as unique identifier for the user instead of the email address has benefits against low-power attackers. The URL-with-GUID has been sent through email, so it cannot be considered as really secret. Motivated attackers will spy on the network lines and see that email. However, amateurs or automated attack bots, while not being able to read other people's emails, may "guess" email addresses, but not random GUID.

The GUID has thus any relation with security only insofar as it is unpredictable, and then it would bring any good only against attackers who are not very powerful. Using the GUID does not harm, but don't believe that it really adds much protection. You might want to make sure that the GUID is generated wit the version 4 algorithm, i.e. 122 bits from a strong PRNG: though GUID aim at uniqueness, you want unpredictability, which is another beast; version 4 GUID ensure both.

Keeping in mind that the GUID is not (really) secret, your system can be described as such: there is a one-time registration password, which is a four-digit PIN. After registration, a normal user-chosen password is used.

The main problem is that the four-digit PIN is too easy to guess: an attacker only has, on average, to try 5000 of them before hitting the right one. You can mitigate this problem by deactivating the PIN code after, say, three wrong attempts for a given GUID; that's the model of smart cards, with your server as the card. However, this will thwart only attackers who do an online brute force.

It unfortunately happens, occasionally, that some attackers obtain a glimpse at some parts of the server database. This is a frequent result of SQL injection attacks, for instance. Discarded old hard disks are also a classic source of such leaks. This is the very reason why you envision storing not passwords of PIN codes, but only hashed versions thereof.

But password hashing, even if done properly, only slows down attackers. If the iteration count is set so high that it takes a full ten seconds of computing for your server to verify a PIN code (and ten seconds are a very long time for a waiting customer), and attacker will "just" need 50000 seconds worth of computation, with the same hardware, to "try" 5000 possible PIN codes. Since the attacker will throw in a couple of multi-core PC, he will probably get down within an hour or two. That's not a lot.

I advise using a longer PIN code, say 8 digits.

To sum up: your GUID is not "secret enough" to tolerate a four-digit PIN, even for a one-time registration page. Using a GUID instead of the email address is interesting and you want it to be as discreet as possible (so use "v4" GUID), but even so, four digits are not enough for a PIN when the verifying system is not a tamper-resistant smart card. Use eight digits (or more). Since the user will type the PIN code only once, he can tolerate a rather long sequence (Microsoft could make users type 25-letter activation keys, so I don't think that 8 digits for registration would be too much to ask).


Why would a remote desktop connection harm my PC?

This is a good question! First a disclaimer that I'm not really qualified to give a complete answer, as I have so far been fairly good at avoiding RDP security issues in untrusted environments. I do use both RDP clients and servers though, but only ever on trusted hosts. That said, I do have a few thoughts why we're seeing such warnings;

It would be fairly reasonable to assume that the majority of security risks would be undertaken by running a RDP server (what Microsoft calls Remote Desktop Services), and there were some quite infamous exploits of it in the past, for example vulnerability to the pass-the-hash or MiTM attacks on non-encrypted connections. We probably still all remember disabling Remote Assistance and removing associated port exceptions in firewalls as one of the first things we did upon installing Windows XP, for example. But risks involved in using a RDP client (or Remote Desktop Connection in Microsoft's terminology) don't seem so self-obvious.

For a more in-depth explanation on terminology used and distinction between a RDP client and a RDP server, please see the update at the end of my answer. But to make things clearer, this is the warning dialog that OP is talking about in the question:

While I haven't been able to find documentation on any recent self-propagating exploits (i.e. viruses, trojans, or worms) taking advantage of Remote Desktop Connections through the use of the updated RDP protocol clients, especially those using TLS, there are still some risks involved with connecting to untrusted RDP servers:

User activity tracking and keylogging: In essence, untrusted RDP server could log all your activity on the server, including websites you browse to, files you download, documents you accessed and were changing, passwords you entered to access remote services through the RDP server, basically keep track of your complete user session.
Infection of client through remote hosted files: Any files you download from the server hosting a RDP session could be tampered with, or infected with malware. You could falsely assume trust in any of these files, thinking since you put them there during your previous RDP session that they weren't tampered with or infected in the meantime, transfer them to your RDP client and open/execute/...
Man-in-the-middle: Similar to user activity tracking, only this time the attacker is active on the RDP server you connect to and is listening in on your RDP client to RDP server connection, RDP server to remote LAN / WAN connections, or possibly both. On top of being able to inspect contents of exchanged network packets, man-in-the-middle is also able to change their contents. The RDP session can be encrypted using TLS, effectively preventing eavesdropping on it, but that isn't necessarily the case with where else you connect to (remote LAN or WAN) using the RDP server.
Social engineering attacks: You could be a victim of a social engineering attack where the attacker gains your trust under false pretense, and cons you into entering a RDP server address that you believe can be trusted in your RDP client while establishing a new session, but the address you entered is actually of attacker's choosing. The attacker could host a RDP server on that address for the sole purpose of recording your login credentials for another, real RDP server you intended to connect to. Thanks to @emtunc for reminding me of this threat!

Honestly, I've probably left out a lot of other possibilities to abuse users trust in the RDP server they're establishing a session with, especially when RDP server can not be trusted but the user assumes this trust anyway, failing to see the potential danger in doing so. But these four example attack vectors should be hopefully enough to demonstrate that there is a clear need for such warnings you're receiving.

Edit to add: Seeing there's some confusion regarding terminology used in my and other answers (which we all use in same way as far as I can tell), I want to clear things up which of the two ends involved in a RDP session is considered a client, and which a server (or a host). These are the excerpts from Wikipedia, to exclude any biased and opinion based explanation:

  Wikipedia on Client (computing): A client is a piece of computer hardware or software that accesses a service made available by a server. The server is often
  (but not always) on another computer system, in which case the client
  accesses the service by way of a network. The term applies to
  programs or devices that are part of a client–server model

  A client is a computer program that, as part of its operation, relies
  on sending a request to another computer program (which may or may not
  be located on another computer). For example, web browsers are clients
  that connect to web servers and retrieve web pages for display. Email
  clients retrieve email from mail servers. Online chat uses a variety
  of clients, which vary depending on the chat protocol being used.
  Multiplayer video games or online video games may run as a client on
  each computer. The term "client" may also be applied to computers or
  devices that run the client software or users that use the client
  software.

  Wikipedia on Server (computing): A server is a system
  (software and suitable computer hardware) that responds to requests
  across a computer network to provide, or help to provide, a network
  service. Servers can be run on a dedicated computer, which is also
  often referred to as "the server", but many networked computers are
  capable of hosting servers. In many cases, a computer can provide
  several services and have several servers running.

  Servers operate within a client-server architecture, servers are
  computer programs running to serve the requests of other programs, the
  clients. Thus, the server performs some task on behalf of clients. The
  clients typically connect to the server through the network but may
  run on the same computer. In the context of Internet Protocol (IP)
  networking, a server is a program that operates as a socket listener.

To put this into perspective how this terminology applies to a RDP session, I'm also including excerpts from the previously linked RDP server (Remote Desktop Services) and RDP client (Remote Desktop Connection) Wikipedia pages:

  Remote Desktop Connection (RDC, also called Remote Desktop, formerly known as Microsoft Terminal Services Client, or mstsc) is the
  client application for Remote Desktop Services. It allows a user to
  remotely log in to a networked computer running the terminal services
  server. RDC presents the desktop interface (or application GUI) of the
  remote system, as if it were accessed locally.

  The server component of Remote Desktop Services is Terminal Server
  (termdd.sys), which listens on TCP port 3389. When an RDP client
  connects to this port, it is tagged with a unique SessionID and
  associated with a freshly spawned console session (Session 0,
  keyboard, mouse and character mode UI only). The login subsystem
  (winlogon.exe) and the GDI graphics subsystem is then initiated, which
  handles the job of authenticating the user and presenting the GUI.

And to put it visually, Remote Desktop Connection client on Windows 8 looks like this before establishing a RDP session:


Windows Encrypted temp directory for files at rest in Windows?

All NT-based versions of Windows since 2000 have a feature called Encrypting File System (EFS), although "Home" and similarly low-end editions can't use it. You can look up more information about this feature from Microsoft as well, but here are some relevant ones:

Encryption and decryption is transparent; keys are managed by the OS and used automatically when reading or writing. There's no "locking" or "unlocking" the files; any process running in an authenticated session for any allowed user will be able to decrypt the files.
You cannot actually encrypt directories, but if you set the Encrypt flag on a directory it will encrypt all files placed in the directory.
All file data is encrypted, though file metadata (name, size, permissions, etc.) is not.
Encryption uses user-specific keys. If you want multiple users to have access to the file, you have to have given each user access before encrypting the file.
The encryption keys are protected by the user's password. If a user forgets their password and needs to have an Administrator reset it, the user loses access to EFS-encrypted files unless the user had previously backed up their EFS key. Changing passwords (where the old password is used) doesn't cause any problems, though.
By default, even local or domain administrators cannot decrypt EFS-encrypted files. However, there's a setting in Windows to automatically grant administrators access.
EFS requires NTFS. Moving a file or directory within an NTFS volume, or across NTFS volumes, will not decrypt it. However, moving it to a volume using any other file system (such as FAT32/exFAT as typically used on flashdrives and SD cards) will decrypt the file if possible, or fail the move if not; these file systems do not support the metadata used by EFS.

BitLocker or some other full-volume encryption (FVE) is usually preferred over EFS these days, although they are suitable in slightly different scenarios. FVE will encrypt the file system metadata, such that an attacker wouldn't be able to read file names. FVE uses newer, more-secure ciphers than EFS. FVE is sometimes easier to use offline (if, say, the computer dies and you connect its drive to another machine) so long as you have the recovery key. FVE is machine-wide instead of user-specific. You can combine FVE and EFS if you want to, although it's mostly redundant.


is it possible to track a ddos attacker if he's using a paid website service?

This is more of a networking question. If the attacker launches the attack from his home without any protections, then the IP will point to his home. If he pays a service to do it, or uses a cloud server, then the IP will point to the service and not his home.

But the service will have records of who paid them, so it is possible for investigators to trace the attack that way.


External command execution in Excel formulas

The functionality to run arbitrary code was an intentional feature that Microsoft added. Back when office was released the whole threat molded was different, we did not share files like we do today. And since Microsoft hate to remove features and break backwards comparability we still have to deal whit this.

  Are the details of this functionality documented anywhere? MS Office
  documentation of external references doesn't do so.

=cmd Appears to be badly documented it can't be found in the list Excel functions (alphabetical), however the VB documentation has example code on how to start the calculator Here

  Is there an equivalent construction in Excel for Mac? The particular example doesn't work, but it could as well be because of cmd (and calc) being windows-specific command names; if the external execution is intentional (as those old vulnerabilities haven't been removed but just had the warnings added) it should likely be implemented in Excel for Mac as well.

Yes, Office 2011 can run arbitrary code POC, In office 2016 Microsoft added a sandbox but it has had issues: ref


wireshark does't show HTTP requests from other devices

Network traffic can be either unicast or broadcast (or multicast, but that's not relevant right now.) NBNS (NetBIOS Name Service) is broadcast, so the switch (your wireless "router" in this case) has a responsibility to deliver it to every host "attached" to it. Most other traffic is unicast, which means the switch should send it directly to the recipient.

Different kinds of layer-2 network devices do this in different ways:

Hubs simply broadcast everything to all their ports, regardless of destination.
Switches keep a table (the CAM table) of which MAC addresses are using which ports, and send unicast traffic to the appropriate port.
Wireless switches without encryption act like a hub, since radio is omnidirectional.
Wireless switches with encryption (oversimplification, assuming WPA) use individual keys to protect unicast data intended for a single recipient, but shared broadcast keys to send broadcast data.

In order to see the traffic destined for some other machine on your network, you need to do some traffic manipulation. Your options generally are:

Use a hub instead of a switch. Not possible in the wireless case.
Sniff directly from the switch (sniffer software installed on the switch.)
Configure a span port on the switch to receive all traffic regardless of destination.
Use ARP poisoning, ICMP redirection, CAM flooding, or other traffic manipulation to trick the switch into broadcasting unicast traffic.


Can I safely disable and re-enable Secure Boot when Bitlocker is used in order to make a Forensic Image?

OK, first things first: if you're trying to make a forensic image of a disk, and you're doing ANYTHING AT ALL that involves booting the machine it's in before you initiate the image, stop and ask yourself why you aren't just removing the disk and cloning it using dedicated hardware. Or at least disabling auto-mount and attaching the disk as removable storage to another PC from which you will create an image or clone of the unmounted volume.
If you absolutely must image the disk in place inside the PC, REMOVE the disk before making any modifications to the system (such as disabling or reconfiguring Secure Boot). Only once you're confident you can boot into your alternate OS, reliably, should you even consider re-inserting the disk. Ideally with a write-blocker in place, but that might not be practical for a laptop's internal drive.
Booting Windows - even as far as the login screen - will modify the data on disk unless it's forced to be read-only. In addition to the changes that Windows itself will make, booting will also start background processes (services) that may do anything else possible in software at all.

Disabling Secure Boot will probably modify the instructions that the CPU executes on bootup, which are one of the things the TPM tracks and determines whether or not the BitLocker key can be released. As such, I expect that yes, you would need to enter the recovery key. If you do enter the recovery key and boot the system, it should then update the TPM unlock to be able to automatically unlock in the future until you change the boot process again. If you don't boot to Windows, re-enabling Secure Boot would probably result in TPM automatic unlock working again.
As for Self-Encrypting Disks, if that covers the entire disk without leaving a single partition in plain-text for boot code (which is what BitLocker normally does), then attempting to image the disk will either just fail (if the unlock requires that the boot process not have been tampered with) or it will image the plain-text data (because the decryption happens transparently on the disk controller). In all other cases (including non-SED), your image would be the encrypted data (plus the small non-encrypted boot volume).


Was Meltdown/Spectre discovered in 1991 or 1995?

The Wray paper is about categorisation of covert channels, and from a rapid reading, it does reference an attack on a cache by two processes explicitly loading memory locations, but to be used as a timing mechanism.

The Sibert paper, in the section 3.10 merely identifies the covert channel, not the actual Meltdown flaw.

In conclusion, although it can sound like Meltdown/Spectre, these papers only identify the existence of the covert channel used in the recent exploits, and have not discovered the vulnerabilities themselves. These are the result of the use of this covert channel over the speculative execution mechanism of the processors.


Ok.  So the reason that ports are visible on the network is fundamentally that a program you have running on your computer has asked to make that port available on the network.

In the case of the services you've listed the following are the common services that will listen

80/TCP - A web server (something like Apache or Nginx)
111/TCP - usually relating to RPC services (like NFS)
631/TCP - IPPP or CUPS, a printing service
902/TCP - likely something relating to VMWare
3306/TCP - Commonly MySQL .

In and of themselves having a service exposed to the network won't necessarily damage your security, but each one provides a point of attack on your host.  So for example if you have a weak password on your MySQL service an attacker might be able to guess that.

In order to stop them listening, you have a couple of options.

If you don't need that service to be running on your PC, then you can stop the associated process.  runnning the command sudo netstat -plnt should show the listening port and the process/program name associated with it.  Ones that show the local address as 0.0.0.0 or [YOUR_NETWORK_IP] are listening on the network and could be contacted remotely.  So once you have a list of the services just shut them down.
If you do need the services but don't want them to be available on the network you can generally make them only listen on the "localhost" address.  How you do that will vary from service to service, but if you search for "binding to localhost" and the service name you should be able to find something
Perhaps the easiest way to address the problem is to run a firewall on the host to block inbound connections as @smokedispenser mentioned in his comment. Assuming you're using ubuntu something like ufw could be worth looking into.

what's probably happened to cause these services to start listening is that you've installed some new software which provides network services.  At a guess have you perhaps been practising web development?


How easy/difficult is it to spoof DNS? Are some scenarios safer/more risky than others?

If the victim is using an open wireless network, spoofing DNS is easy.  It is easy for the attacker to mount a man-in-the-middle attack and send forged DNS responses.  Therefore, if you are using an open wireless network, you should not trust DNS at all: it is trivial to spoof.

Similarly, if the attacker is on the same subnet as you, spoofing DNS is easy: in this case, it is trivial for the attacker to eavesdrop on your DNS requests and then spoof responses and play man-in-the-middle games.

If the victim is using some other network, spoofing DNS is not easy but potentially feasible.  If the victim is connected to the network via a wired network, in most cases the attacker can't easily arrange to eavesdrop on your network communication.  In this case, the easy man-in-the-middle attack no longer applies, and the attacker has to work harder.  There are still some other possible attacks, but they are not nearly as easy to mount:

Kaminsky attack. If you have an older DNS client (one that doesn't use source port randomization), the only protection against spoofing is a 16-bit ID field.  16 bits is not enough to defend against random guessing, and Dan Kaminsky showed how to spoof DNS under these conditions.  Therefore, if you have an old DNS client that doesn't use source port randomization, you should assume it is easy to spoof DNS.

Fortunately, after Kaminsky discovered his attack, there was a concerted effort to add defenses against his attack (e.g., by randomizing source port IDs), and most modern clients do use source port randomization.  Therefore, for modern DNS clients, while Kaminsky's attack is still possible in principle, it would require an awful lot of traffic, so it'd be possible but non-trivial to mount such an attack; unless you are a high-value target, you're probably pretty safe if your DNS client uses source-port randomization.  However, there are still some systems that have not deployed protection against the Kaminsky attack, either because they are very old, or because they are embedded systems that haven't been updated, or because they are behind a NAT that destroys the source port randomization -- and those systems remain highly vulnerable.
DNS cache poisoning.  In the past, many DNS caches were vulnerable to cache poisoning attacks, where an attacker could fool them into accepting a malicious reply to a DNS query and then cache that malicious reply.  Then all subsequent clients who use that DNS cache who query that name would get the incorrect and malicious answer.

These days, modern DNS software has been updated to defend against all known cache poisoning attacks, so cache poisoning attacks should be difficult to mount today.  It's possible there might still be a few DNS caches out there running very old software, but I'd expect them to be pretty rare.
Client-side malware.  One thing that some client-side malware does is modify your system's configuration so that all DNS queries go to the attacker's DNS servers.  Thus, if your machine has been infected with this malware, the attacker gets to spoof DNS easily.
Drive-by pharming.  If you connect to the Internet via a consumer/SOHO-grade cable modem, DSL modem, personal wireless access point, or similar device, you may be vulnerable to a nasty attack known as drive-by pharming.  In a drive-by pharming attack, the attacker reconfigures your router to change its DNS settings, so that all DNS queries go to the attacker's DNS servers.  If the attacker can do this, it thereafter becomes easy for him to spoof DNS.

How can this happen?  One way: If you run an open wireless network, an attacker who is physically nearby may be able to hop on your network, connect to your router at a standard address (e.g., http://192.168.0.1), and if you haven't set a strong password on it, guess your password and change its configuration.  A little more subtly, even if you have chosen a strong password, if you are logged in, the attacker might still be able to change the configuration, by exploiting the fact that many routers' local web configuration interface does not defend against CSRF attacks.

Worse, in some cases these attacks can be mounted remotely, by an attacker who is on the other side of the world.  If you are using a vulnerable router, and if you are currently logged into your browser or if you haven't set a strong password on your router, if you visit a malicious web site, the malicious web site may be able to use Javascript and Java to connect to your router (from the inside interface), guess your password or exploit a CSRF attack, and change its DNS configuration -- invisibly, in a way that you have no idea happened.

Unfortunately, many deployed routers are vulnerable to these attacks, and because there is no good channel for deploying security updates, this fact is not likely to change any time soon.  I would rate this attack as medium difficulty; it's probably not too hard to find some users who you can attack in this way, but might be difficult to attack a targeted user (unless you are physically nearby).
Server-side hacking.  If the attacker can hack a DNS server that is responsible for example.com, then the attacker can control the responses that are sent when clients ask for the IP address of example.com.  This attack is probably relatively difficult for most sites, but the difficulty will vary depending upon the target.  One study found that 17% of DNS servers have known vulnerabilities.

This attack is worse than it might first seem, because there is a great deal of transitive trust in the DNS.  For instance, the Government of Ukraine's web site depends indirectly upon Dreamhost's DNS servers (kmu.gov.ua's DNS is served by servers at adament.net; adament.net's DNS is served by dreamhost.com), upon Norway's and Sweden's DNS servers (ua's DNS trusts sunet.se, which relies upon nordu.net, which relies upon no), and upon a number of other DNS servers.  Therefore, if you can hack any of those DNS servers, you may be able to spoof DNS for the Government of Ukraine's web site.  The amount of such trust varies significantly from site to site.  One study found that 45% of DNS names are susceptible to hacking, due to indirect dependencies of this sort upon vulnerable DNS servers.

Bottom line. Overall, I'd say that if if you are using an open network where the attacker can eavesdrop on you, then spoofing DNS is trivial -- whereas if you are using some other network where the attacker can't eavesdrop upon you, then spoofing DNS is pretty hard but far from impossible.

Therefore, I think there are good reasons to use solutions like DNSSEC and SSL/TLS.


Solutions for accessing webapp from inside and outside the corporate perimeter by same users?

Sounds like a job for Azure AD Connect, then your app can authenticate against Azure AD regardless of where the user is (interal/external to the company's lan).  As long as they can reach your app they'd be able to log in with their credentials.

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect