Internet traffic redirect from WAF to Cloud Network - Encrypted vs unencrypted What are security best practices to determine if WAF should redirect Internet traffic to cloud network as encrypted or unencrypted ?

Best practice is to encrypt all traffic - especially if it touches any network equipment you do not entirely control.

If the WAF is on a different LAN to the server network why would you not encrypt it? If your servers accept unencrypted traffic it to a large extent makes the WAF redundant - a malicious actor could just send the traffic direct.

There have even been instances of security agencies accessing traffic within internal communications. Google now trust absolutely nothing.


Meterpreter & Vuln Server I learn Shellcode and use Vulnserver.exe.
I managed to get to the point that I inject a shellcode like open a calculator or msgbox
But for some reason bind shell on port 4444 does not work for me.

Here is the source code:

The shellcode is form meterpreter windows/x64/shell_bind_tcp.
Please help

Based on what you gave so far, it seems you are attempting to exploit a buffer overflow.

  I managed to get to the point that I inject a shellcode like open a calculator or msgbox

I'm going to assume then, that the calc or msgbox is just a payload that you used in the shellcode variable. With these, I can think of a couple of reasons why you can't get the bind shell working.

The bind shell works, but firewall blocks you from connecting. Its port 4444 as you mentioned, so its possible. Use netstat on the victim machine and verify if the port is listening or not. If not, then there really is something wrong with the payload.
There are bad characters in the bind shell payload. Do a bad character analysis, encode and filter them out, and try again.
You are using an invalid payload. This applies if your system is 32-bit.
There is a size restriction on the payload size, and you exceeded it.
The payload steps on its own foot. Try putting NOPs in the first 4 to 8 bytes of your payload (Although this one is unlikely if you didn't encode your payload).

These are just the common reasons I can think of as to why your bind shell doesn't work. Hope this helps.


Two-factor authentication methods: password + SMS/voice message vs. password + app-generated code? I am thinking which methods of two-factor authentication are most reliable and secure when using Pebble as an user end who has the capability of seeing his or her SMS messages but not answer phone calls:

password + SMS (two places where shown) OR password + voice call (only received by your phone)

Both of which are visible in the case of theft of your phone.
Compare this method to using a password + phone app generated one-time code in Android system.
I cannot evaluate the security of the application for generating one-time passcodes in the Android phone. Access to it depends on having your passcode to your phone. Intuition suggests that it might be stronger than SMS/voice call. But what about possible vulnerabilities in the app.

How can you evaluate the security of these two methods?
Why a well-designed app in Android is more secure than SMS/voice call?

A well-designed app on your phone is more secure.

There are a large set of vulnerabilities in the delivery of either phone calls or text messages.  They include messing with telephone routing tables, and systems such as  which can collect text messages and route them as email.

If your phone is running an app, then these delivery and routing issues don't matter.   If it's insecure, either because it's stolen or taken over by an attacker, then you're out of luck in either scenario.


Smart Card private key usage How does an application get the private key from a smart card in order to sign some data?

I presume that the data is being signed by a code running on the main OS (Windows/Linux) and not on the smart card device. am I correct?

Also, some smart cards involve PINs in the process. Does the PIN add value?

Smart cards that are used for cryptography do generate and use the asymmetric key on the device. They typically employ mechanisms to try and prevent extracting of the private key. This includes wiping the key material when a PIN has been entered wrong too many times. There has been lots of research into using cryptographic side-channel attacks to extract information by observing the smart card during crypto operations.

As for how applications interact with the smart card, every system I've worked with in the past has used a combination of OpenSC and the PKCS #11 interface it provides. PKCS #11 is the standard for interacting with cryptographic hardware devices like smart cards and HSMs.


How strong is visualCaptcha? I like the user interaction of visualCaptcha, but I'm questioning the amount of protection it gives:

Since there are only 5 images (by default), isn't is simply a matter of 1 in 5 to get the right image?

Also, the whole process is initiated by sending a start/X request, where X is the number of options to generate. As far as I can tell, a bot might initiate with X = 2 instead of 5 and get 50% of the tries right.

There are two considerable weaknesses in the live demo which make it quite trivial to break:

There are only 5 possible answers to the captcha question, so a bot has a 20% chance to solve the captcha by picking a random symbol. The demo didn't ban me after picking a wrong answer over 20 times in a row, so there is no reason why a bot can't just keep guessing until it got a correct answer by chance.
There is only a very limited set of images which are in no way altered. They appear under different URLs, but always look the same, so a bot can identify them by loading and decoding the images. Also, the system refers to each image with the same word every time. That would allow to simply tell the bot which word means which image.

Some ideas to make the captcha stronger:

Ask the user to mark multiple objects and only let them pass when they marked these and only these objects. That would make random guessing much less efficient.
Ban IP addresses for a few minutes after many wrong answers in a row
Use a much larger set of images
Use an even larger dictionary of strings to refer to them
Use image altering algorithms with randomized parameters to alienate the images a bit so it gets harder to recognize them automatically

Keep in mind that no captcha is truly unbreakable. All you can hope for is to increase the effort an attacker needs to invest to break it. But that can be all you need. Captchas are one of the few areas where security through obscurity can pay off. Spammers look for low-hanging fruits. When you use an obscure home-brewed captcha solution and aren't a particularly valuable target, many spammers will just be too lazy to figure it out. When you are a particularly valuable target, they will just hire a bunch of people from a 3rd world country to solve your captchas. And you can not defend against this without also making your website unusable for regular users.


Is CVE2012-5373 fixed in OpenJDK7? Can anyone please tell me if CVE2012-5373 is fixed in OpenJDK7? I have searched for the fix details, but I couldn't find any.

This CVE is not fixed in OpenJDK7. Both Debian and redhat report it as unfixed:

https://security-tracker.debian.org/tracker/CVE-2012-5373: unfixed
https://access.redhat.com/security/cve/cve-2012-5373: Will not fix


Will Enabling TLS 1.2 and disabling older protocols on Windows Servers have any impact on desktops? I want to know what the impact would be if I were to enable TLS 1.2 on Windows Servers and disabled older protocols. I enabled TLS 1.2 on my Windows 7 Laptop manually running the Microsoft Fix It script and it broke my VPN connection, but that's for another thread.

If you only enable new protocol, then there is no impact for existing applications as long as you do not disable others. SSL/TLS protocols in Windows are implemented side-by-side and one protocol do not affect other protocols. But if you disable any other protocol, applications may fail if they explicitly rely on a disabled protocol.


How does OWASP ZAP find Reflected XSS? What I'm doing:

I'm using OWASP Zap to find vulnerabilities in a site (I  have the owner's consent) and Zap came up with a Reflected XSS Vulnerability after I did an active scan on a POST request. It told me that the variable "cn" (the username) was vulnerable to reflected XSS and that the payload "><script>alert(1);</script> would work.

My process:

I went ahead and tried to enter this into the input field called "cn". The input field had a maxlength of 12, I went ahead and did a quick inspect element it and changed that. Then I entered the payload, put in a random value for the password input field and clicked submit.

The Result:

Unfortunately an alert box did not pop up, just a wrong username and password message. I did notice that a little "> that appeared after inserting the payload. When I looked into this I found that the script tag had caused the "> to be parsed as regular characters.
<input type="text" name="cn" size="20" maxlength="20" value="<script>alert(1);</script>"> is the html. The "> should not have modified the js though.

The Conclusion

UPDATE: So after thinking about this in the shower I realized the whole point of reflected XSS... that the value provides to the user had to actually be reflected back. The un parameter was never actually being reflected back to me. But this still doesn't answer the question... why did ZAP pick this up as a XSS vulnerability when there clearly is not any XSS?

These automated checks work by putting a script tag containing a random token into every field. For example, /someRequest?foo=x&bar=y might become:

GET /someRequest?foo=<script>alert("147230578")</script>&bar=<script>alert("561972456")</script>

It maintains a map of fields and the random values it chose (in this case foo=147230578, bar=561972456) in order to trace which parameter is injectable.

It then checks to see if <script>alert("147230578")</script> or <script>alert("561972456")</script> appear in the page without encoding. If the string is found, it knows XSS is very likely possible. If not, it either didn't appear in the page at all or it got HTML encoded.

In your case, it found that if it did get those strings reflected back, and identified which field was injectable. The reason it didn't execute is that the script tag got injected into a HTML attribute.

So, looking at your injection:

<input type="text" name="cn" size="20" maxlength="20" value="<script>alert(1);</script>">

What happens here is the HTML is malformed, so the browser's renderer just tries to make the best of it, ignores both tags, and closes everything after the </script>. It then sees "> which it assumes is content and renders it on the page.

If we instead inject "><script>alert(1)</script> into the parameter, we get this:

<input type="text" name="cn" size="20" maxlength="20" value=""><script>alert(1)</script>">

This time the input tag is closed, which causes the script tag to get executed. Successful XSS! Again, the "> at the end just gets treated as content.

For a bonus round, what might we do if the vulnerable parameter doesn't allow the use of triangle brackets? Since we're already in an  attribute, we can manipulate the input element we're injecting into in order to execute script:

" onmouseenter="alert(1)" x="

This creates the following output:

<input type="text" name="cn" size="20" maxlength="20" value="" onmouseenter="alert(1)" x="">

Note that the x attribute doesn't do anything, it's just there to let us maintain valid HTML; unknown attributes are just ignored.

In this case, when the user's mouse enters the input element, it executes the JavaScript and we get XSS again.

But requiring user interaction sucks! We could use onload but this is often finnicky. Instead we can utilise some CSS tricks to force the user interaction:

" onmouseenter="alert(1)" style="display:block;position:absolute;top:0;left:0;width:50000px;height:50000px;z-index:999999;

This then becomes:

<input type="text" name="cn" size="20" maxlength="20" value="" onmouseenter="alert(1)" style="display:block;position:absolute;top:0;left:0;width:50000px;height:50000px;z-index:999999;">

The style here looks like a mouthful but it's quite simple:

Make the element display as a block element (so we can size it arbitrarily)
Make the element's position absolute within the window (so we can set its position to anywhere)
Move the element to (0,0)
Make the element completely fill the page (so the user's mouse has to enter it!)
Make the element appear on top of everything else.

Hopefully this explains how this all works and how you can go from the example given by ZAP to a working XSS exploit.


Forensics in the cloud I recently did a university module on digital forensics and learned a lot about the process, and techniques, of digital forensics investigations.

We didn't actually cover the cloud although I couldn't stop thinking about how it would work. Although we can access the virtual machine image, and all of the files/logs etc on them afterwards, there are a couple of things we don't have access to.

First of all the physical disk (both RAM and the physical hard drive the VM was hosted on), and the network logs, are out of bounds to a user from a remote location. But I was wondering what else there might be that I haven't thought of which would be of use to a forensics investigator?

The logs of the cloud service provider themselves would be the most valuable.  The cloud service provider is going to keep logs about the state of the system that extend beyond what is available to the user and would provide a lot of insight in to an intrusion.

Keep in mind that not all cloud services use virtual machines either.  They can be as simple as different users on the same service.  You are pretty much at the mercy of the cloud service's logging, but that generally will be better than private industry since cloud services have to focus on up-time for their business, which means finding problems early, which generally means extensive logging.


Jumping to shellcode: Blind return In famous buffer overflow tutorial by Corelan Team (part 2) a technique called "blind return" is mentioned.

  So if you overwrite EIP with the address that will perform a RET instruction, you will load the value stored at ESP into EIP.

and further down

  Overwrite EIP with an address pointing to a ret instruction
  Hardcode the address of the shellcode at the first 4 bytes of ESP

I don't get the advantage of this approach. You need to hardcode the address XXXX at the start of the shellcode (ESP).
Wouldn't it be easier just to overwrite EIP with XXXX directly to get the same effect?

By overwriting eip do you mean to directly overwrite ret address or fill the stack with some buffer

Because usually when there is a stack without canary and a bof present you can basically fill the buffer with nop+shellcode+addrof buff (generally on stack or some writable memory)

So the eip points to the address of the buffer on stack and hence the shellcode in buffer would be executed


Alternatives to hardcoding or encrypting key material in source code What is best practice as of 2019 for storing secrets inside applications?

Sometimes in an app, you might need to access some web-resource or other asset that requires authentication or decryption.

What is the best practice to achieve this?

I've seen folks hardcode symmetric keys, etc but I feel this is a bad way to do things.

Even if the key is encrypted you still need to decrypt the key before use.

Using secure enclaves in iOS or keychains make sense but still, you'd need to onboard each client to the resource with their public key so this seems suboptimal (also you'd need to authenticate each client)...

What is best practice as of 2019 for storing secrets inside applications?

Best practice? Don't do it.

Its hard to answer your question without any context - what sort of "app"? What are the constraints? What is the threat model? What usages for the secrets?

If you are authenticating the user's interaction with the app, and the built-in capabilities of the client are insufficient, and you need to provide local then stored a suitably hashed representation of the user's passwords as data.

For anything which needs to be maintained as clear text, and which you cannot control the rotation of, and where your app will never see the user's password (or needs to run without an active session) and the secrets need to be available offline then encrypt the data using a master key, and for preference rotate the master key regularly (which is starting to sound a lot like building the kind of capability provided in most modern runtime environments). But this is a very undesirable situation - so should be the last option you choose.

If the app will only be used online (or only requires access to the secrets when online) then use an online store for the secrets authenticated by a changing token stored on the device.

Thee are so many other options I could be here all day painting scenarios and proposing what I think is the best solution.


Shared Text Content - XSS Safe I have a bulletin on my site that all valid users have access to (read and write). User input posted to this bulletin is stored in JSON. Because of these qualities there is definitely some concern for XSS. Im hoping to figure out the best way to protect my app and its users when using this feature.
Some thoughts:
Validation - because this is a bulletin/message board I would prefer to allow users access to any character they can type. One user might need to say Boss says "Specials for ages < 12 & > 65 are as follows...". Because of my requirements, validation does not seem possible.
Sansitization - this has the same issues as validation, we would lose functionality.
Encoding - Im fairly new to this and do not know how one might encode user input to make it safe within the DOM (or JSON). If this is the preferred route I am interested in links to documentation or examples.
More Context:
I am adding to the content by doing something similar to the following; where obj is the full entry and message is the user supplied input.
var body = $('<p>').text(obj.message);

Because I am only adding user input in the text context does that mean I can avoid concern?
Lastly, I am newer to using JSON to store user supplied info. I have not been able to find much on JSON security but if you have any topics related to the above, I would appreciate links to documentation.
EDIT: a user here said the following:

Note that this function also does the reverse - so calling it on
already escaped data will result in it being unescaped which can
inadvertently result in an XSS

Is this correct?

JSON is merely a data interchange format, and has no inherent "vulnerabilities" of its own.
Also fortunately for you, the text takes the input and renders it as plain text in the given element.  As a result there is no concern for XSS.  Note though that it is only the use of the text method that protects you.  If later on you decide that you want to also inject your own formatting so do something like this:
var body = $('<p>').innerHTML = '<strong>' + obj.message + '</strong>';

Then you will absolutely end up with a stored XSS payload.  This is one of the good reasons to use front end frameworks like Angular and React.  They automatically handle output sanitization for you, so you don't have to worry about these things.
Finally, for completeness, sanitization/encoding are more or less the same thing, and are quite possible.  You would just need to replace " ' < > & with their HTML equivalents, and that will work in 99.9% of cases.  Still, it's even safer to use a framework that will handle those details for you.


What are the potential privacy issues in using a TPM chip with GNU/Linux I'm planning to buy a TPM module to bring more security in my system (GNU/Linux, dm-crypt/LUKS, SED) but I'm not sure with the big debate around it.

What are the (possible) privacy concerns in using a TPM chip ?
Can my keys or my datas be leaked to government agencies or criminals ?
Can my OS be infected using the firmware in the chip as an attack vector ?

The TPM compromising the OS is pretty unlikely. The chip talks to the host computer via a low-speed serial bus comparable to a serial port; the code handling data received on that port is much simpler than let's say USB-related code, so if someone wanted to own the machine they would rather use USB-based solutions (especially since you don't even have to exploit any vulnerabilities in USB-handling code as USB has a built-in vulnerability : it trusts any USB keyboard right away).

Now, whether the TPM is good at what it's supposed to be doing is a different issue. Personally I don't trust TPMs for full-disk encryption as the key is transmitted unencrypted over the LPC bus, so for someone with physical access to a machine (even turned off) all he has to do to own it is to connect a logic analyser to the LPC bus and grab the key from there. Once that's done the attacker defeated the FDE even though the machine was off, thanks to the TPM.

As far as other uses of the TPM where it generates and holds a secret key, it comes down to whether you trust the manufacturer to not have put in a secret command that would make the TPM spit out the key it was supposed to protect (or a "bug" that would allow running arbitrary code on the TPM), as well as trusting the manufacturer to have sufficiently hardened the chip against hardware attacks.


What could an "<img src=" XSS do? Most WAFs when blocking XSS will block obvious tags like script and iframe, but they don't block img.

Theoretically, you can img src='OFFSITE URL', but what's the worse that can happen? I know you can steal IPs with it, but is that it?

Firefox (fixed in Nightly 59.0a1), Safari (fixed in Safari Technology Preview 54), Edge, and Internet Explorer display an authentication dialog if you request an image and the server asks that you authenticate with HTTP Basic authentication. This allows an attacker to display an authentication dialog when a user's browser tries to load the image:

Firefox. Fixed as of Nightly 59.0a1, but the warning present in latest stable release:

Safari. Fixed as of Safari Technology Preview 54, but the modal is still present in the latest stable release. Note that it's a modal dialog and the rest of the website is grayed out. "Your login information will be sent securely" is also technically true but may give a careless user the wrong impression:

IE11. A native Windows dialog locks up the whole browser:

If you make the realm a really long string of a\ta\ta\t...a\t, IE11 completely locks up.

A well-chosen domain name and realm can trick users into sending their usernames and passwords to an attacker's server, or make your website completely inaccessible.


Who is the Mandatory Access Control Administrator Would a mandatory access control implementation administered by a 'normal' user be discretionary since the user could change permissions as he sees fit? And if so, wouldn't root as a MAC admin, being a system user who's privilege could be acquired through legitimate or illegitimate means, also make the MAC implementation discretionary?

In other words is MAC mandatory only if it is immutable? I.e. administered by the OS kernel itself?

You're hitting upon one of the dirty secrets of infosec: MAC and DAC are fundamentally the same thing. They both provide access control, they just have different concepts what a "user", an "administrator", and a "resource" are. There's a reason that MAC didn't become popular until the age of computers administered by people who don't actually use them themselves: on a multi-user mainframe, DAC ACLs set by root look a lot like MAC in practice.

Conversely, take an example of a state-of-the-art "pure" MAC system: Apple's seatbelt profiles, based on BSD's kernel-enforced MAC, are famously used in iOS to prevent even the owner of the device from running anything outside of a sandbox. The real permissions in this case are provided by "entitlements": XML files with a list of perms signed by Apple and included in the binary. In this system, Apple is the MAC admin. No one has a problem calling this MAC, though it looks a lot more like DAC on their own engineering models, where they sign some magic code to let them break the rules.

The real difference between MAC and DAC systems is that MAC systems typically have a more comprehensive notion of the resources to which access is controlled. DAC generally will not prevent you from opening a network socket; MAC might. MAC might prevent IPC; DAC probably won't. Allowed system calls are pretty granular in MAC, not so much under DAC.

Of course, you could get many of the same effects by partitioning programs into individual user accounts and using DAC, because MAC and DAC are fundamentally homomorphic. They just differ in which philosophies they best align with.


What to do about vulnerability in a SaaS product I buy? I work for a university, where I am part of the team responsible for integrating a SaaS Learning Management System (eg: Moodle, Canvas) with the rest of the university's systems.

Two months ago, I identified a CSRF attack, available to anyone who can add course materials to the system (mostly lecturers, but also other academic staff and tutors). The problem is that course materials can contain javascript, and any admin user viewing the course materials (eg: in response to a support request) will run the javascript. As the system now sports a (publicly documented!) REST API, it is possible for said javascript to, among other things, elevate any user to being a System Administrator. Notably, the web site itself uses the REST API throughout, which means that javascript must be able to make API calls. I've developed functional exploit demos, so I know for sure that it works, and how easy it is to do.

I reported it to the vendor, and their immediate response was 'Lecturers are trusted users, this is functioning as designed.' To which my irate response was 'I don't trust lecturers to be system administrators'. According to a simple DB query, we have some ~4000+ users in the system who could upload javascript materials, out of ~50000 users total. Two months later, they are still sticking to their original response.

I'm a little worried about my own institution's system: I've implemented some external monitoring scripts to tell me if any unexpected admins appear, and we do have offline backups, which is about all I can think of to do. However, I'm also bothered that this exploit affects all such installations all over the world, and it's a commonly-run system (probably >1000 instances).

As this is SaaS, we don't have enough access to the system to be able to block it ourselves.

So I have a group of related questions:

Is this attack acceptable, or at least common among large enterprise systems?
I believe wrapping user-generated content in an iframe with the sandbox attribute would block this attack (provided admins use up-to-date browsers), by using CORS to prevent requests to the REST API. Is this safe? Is it otherwise possible to make user-uploaded javascript safe?
If the vendor refuses to fix it, what are my next moves? Is public disclosure recommended, given that it is fairly easy to exploit once it is known about?

EDIT: To answer the comments:

I admit I'm a bit hazy on the difference between csrf and xss, despite reading articles on it. By this definition it's XSS in that it 'execute in some way a script', but it's CSRF in that it has to 'use a victim's already logged cookie/session'. Also, the token that is key to the exploit is called a csrf token by the vendor.

Here's some more detail on how the exploit/mitigation works, per (2). Although you're right; this should really be a separate question.

The attack is to include a fetch request in the supplied javascript that does a PATCH REST request against the appropriate API, in which case the victim's cookie is used as authentication for the API. Non-GET requests require a custom header (an 'xsrf' token), but it's possible for the supplied javascript to scrape that token from another page.
As for the proposed mitigation: course contents, including all user-supplied javascript, are currently wrapped in a single div. I propose replacing the div with an iframe that fetches the user contents separately (or uses a srcdoc), and has a sandbox attribute without the allow-same-origin flag. That would mean the script wouldn't have access to the authentication cookie, and wouldn't be able to make fetch requests to the API anyway because of CORS.

Is this attack acceptable, or at least common among large enterprise systems?

No, this is absolutely not acceptable at all. And I do hope it is not common.

  I believe wrapping user-generated content in an iframe with the sandbox attribute would block this attack (provided admins use up-to-date browsers), by using CORS to prevent requests to the REST API. Is this safe?

In theory a completely sandboxed iframe would help. But as you point out, support for the sandbox attribute is not perfect. It only takes one administrator with an old browser for you to be owned.

  Is it otherwise possible to make user-uploaded javascript safe?

You could take a look at how sites like JS Fiddle solves this problem. They echo the user generated content back from a different domain, thereby levereging the browsers SOP for protection.

But if you are buying SaaS, it should not be your role to fix this.

  If the vendor refuses to fix it, what are my next moves? Is public disclosure recommended, given that it is fairly easy to exploit once it is known about?

In your role as a customer, I would recommend you get the lawyers on the case. If your contract is any good, the company delivering the system is in breach of it. If you are paying for a product with different permission levels, you should make then deliver one. Currently, they are not.

In your role as a researcher who found a security vulnerability, I would recommend responsible disclosure. Among other things, you should give the vendor a clear deadline before you disclose.

  I admit I'm a bit hazy on the difference between csrf and xss.

As others have pointed out, what you describe is stored XSS and not CSRF.


Website showing entered credit card number as valid or invalid I noticed on a website that when I entered my credit card number, the entry box was highlighted blue:

I then tried a dummy credit card number, which made the box highlight red, indicating that credit card number can not be used:

I then tried entering other credit card numbers from expired credit cards and the box highlighted blue again, so the page is checking if entered credit cards belong to an actual card.
Is this a secure practice? Because I could iterate all number combinations and discover which numbers belong to an existing credit card.

I suspect that the site is simply checking that the card number passes the Luhn test.  This is a simple test, based on a checksum, that many sites do to check for typos when entering the card number.
However, even if the card number entered passes the Luhn check, it may not be a valid card number for a currently active card.  And, even if the card number is valid, the issuing bank may not approve the charge.


How to trace someone's(hackers) IP who made a lot of request on my website? Somebody made a lot of(unusual, like never before) http requests on my website, I checked this thing on google analytics and it shows that someone with no lang, no country has visited my website. My website has some sensitive data(personal) that should not be stolen(mobile numbers + emails).

Now I'm worried if someone did find some loophole on my website and tried to steal my data. Can I trace that person who made some unusual requests on my website?

I tried to search on google to find out "how to find a hacker" or something like that but I couldn't get any appreciable info there.

To find more information about who owns an IP address you can:

use the traceroute (unix) / tracert (windows) command line tool to find out which routers are between them and you.
check a GeoIP database to get a very approximate geographical location of that IP address block.
use the ripe database to check to whom the IP address block is registred, which will usually lead you to their ISP.

The exact identity is only known to the ISP which will usually only reveal it when they get a court order or similar official request from law enforcement, which requires that you report it and that they find the case relevant enough to act. Unless you actually lost data or have other tangible damages, they are unlikely to act, though.

Also, when the attacker knows what they are doing, they will use various anonymization tools to hide their identity. There are various methods to make deanonymization of internet users very difficult (which are explained in greater detail in lots of other questions on this site, so I won't go into further detail). Following the IP will likely lead you to just some hapless internet user who got his machine infected with a botnet trojan.

But acting after an attack is really not what you should be worrying about. What you should be worrying about is making sure that such attacks won't work on your systems.

Scans like that happen all the time. When you put a webserver online it usually only takes minutes until people start hammering it with all kinds of exploits. If you aren't confident in your security, you shouldn't be doing this.


Potential issues allowing users to set any URL as web hook I’m still in the planning stage so this may not be fully fleshed out, but I’m working on a SaaS project. Part of which allows users (customers of my SaaS) to configure my API to watch for events and respond in a preconfigured way. One response is for my API (built in PHP) to kick off a POST HTTP request to a URL provided during setup, with given parameters. It is intended that user will point these requests to their own server or other internal system and then be able to listen for these requests and integrate it with their own internal email/tracking/payment systems.

However, I’m a bit worried about giving these users free reign over who they get my server to POSTs requests too. Assuming I sanitize the URL input and any parameters, and throttle the number of requests it can send out, is there any potential malicious use cases stemming from a user triggering POSTs from my API?

I would worry about giving users an arbitrary endpoint configuration.

It might be an idea to validate the domain ahead of time.

Example:
goodguy.com signs up, send an email to admin@goodguy.com to perform the domain validation, or have them set up a txt DNS record you can query to validate there ownership of the domain.

All the other measures are a must as well, rate limiting, sanitisation etc but you really should validate the user has the right to be sending automated requests to the domain.

  is there any potential malicious use cases stemming from a user triggering POSTs from my API?

A couple of the top of my head:

Very slow brute force attack, rate limiting would not catch this
Multiple account sign up, DOS attack, i.e 1000 fake users sign up and all fire a complex post request somewhere
Using your service as a mask for malicious requests, i.e I send a bunch of malicious payloads from a server I control while simultaneously spamming the same target from your server, this puts your server IP in the victims logs along with me


samdump2 Error reading ControlSet: _RegOpenKey I copied both SAM and SYSTEM files from my Windows7 OS, and then used this command to read the content of the SAM file samdump2 SAM SYSTEM > mdp_chiffres.txt, but i'm getting this error Error reading ControlSet: _RegOpenKey.

PS : I have a dual boot of Ubuntu 15.10 (Linux) and Windows 7, and this operation i mentioned above is being operated from Ubuntu.

well i got it to work by following theses steps :

You have first to install a compatible version of samdupm2 and bkhive (because I have tested the ones on the repositories and it doesn't work well) using this commands :

curl http://http.us.debian.org/debian/pool/main/s/samdump2/samdump2_1.1.1-1.1_i386.deb > samdump2_1.1.1-1.1_i386.deb

dpkg -i samdump2_1.1.1-1.1_i386.deb

curl http://http.us.debian.org/debian/pool/main/b/bkhive/bkhive_1.1.1-1_i386.deb > bkhive_1.1.1-1_i386.deb

dpkg -i bkhive_1.1.1-1_i386.deb

Ps : If you have problems with dependecies then execute this command sudo apt-get install -f
Then you have to use bkhive on the SYSTEM file with this command bkhive SYSTEM keys.txt.
And finally we use the samdump2 to get the hashed passwords using this command samdump2 SAM keys.txt > hashed_passwords.txt.

I have just tested it and it works just fine.


Can university vpn see the websites i visit? I am required to login to the university VPN when I am off-campus, in order to connect to a server to submit assignments for a specific class. Is the university able to see what I am doing while I am connected to the VPN? It is called cisco anyconnect secure mobility client.

It depends on whether or not the connection to the VPN is a split tunnel connection.
If it's a split tunnel connection, then only connections to hosts that are on the same internal network as the VPN end point are routed through the VPN.  All of your other connections (e.g. to public websites such as Google, StackExchange, etc.) are not routed through the VPN.  In this case, the operator of the VPN (your university in this case) would only be able to see the hosts that you are connecting to which are on the same internal network as the VPN, and would not be able to see the hosts that you are connecting to which are not on the same internal network as the VPN.
If it's not a split tunnel connection, then all of your connections are routed through the VPN.  Therefore, the operator of the VPN  would be able to see all of the hosts you are connecting to while you are using the VPN.
A simple way to test whether or not it's split tunnel connection is to do the following:  1)  With the VPN deactivated, point your web browser to www.whatismyip.com, and note the address that the site sees you connecting from.  2)  Activate the VPN, then point your browser again to www.whatismyip.com, and note the IP address that the site sees you connecting from.  If the IP address is the same in both cases, then it's not a split tunnel connection.  If the IP address in (2) above is not the same as the IP address in (1) above (i.e. the IP address in (2) above is an IP address assigned to you by the VPN), then it's a split tunnel connection.
Notwithstanding all of the above - if your connection is routed through the VPN, and you connect to a site using HTTPS then (barring a MITM   or similar type of attack), the operator of the VPN would be able to see which sites your are connecting to, but would not be able to see the information transferred back and forth between you and the sites that you visit.


The history of thumbnails (or just a previous thumbnail) is embedded in an image file? I was surprised when I cropped an image on Windows Phone, saved it, sent it via e-mail to a PC, and then downloaded it - and the thumbnail in the download folder was the one of original, not cropped image for a few seconds until finally it would refresh to the expected one.

Maybe I just don't know something obvious, but because I couldn't find any information on image file thumbnail history, jpg old thumbnail stored in file and similar searches, I think that while it may be a known functionality of some image formats, then surely not known widely enough by users. An unaware user might make a photo with private data, crop the private data out and send it to someone, and this private data can not only be possibly acquired from a thumbnail by the intended receiver, but the image may be traveling from hands to hands - there might be millions of images over the Internet which contain private information in old thumbnails.

Here's some examples:

A photo of an identity card can be watermarked for a specific company with a company's name and a date, e.g. Quizzacious Systems 2016/03/05, to confirm an identity of a player which forgot a password; if a support employee has evil intentions, he can take a previous thumbnail of the image, which has no watermark, and use it to confirm his identity as this person - thumbnails in extra large size actually have a comparable resolution with cheap cellphones and may be accepted as a proof of an identity at least by some companies.
A photo of an identity card or anything else with some information censored out by black rectangles - everyone with minimum knowledge knows, that a black rectangle in some formats is not just another layer of data, but removes the original data behind it; at least that's what I thought before discovering this vulnerability. It seems, however, that you can take a censored image and read censored data from it's old thumbnail - the resolution might be too low for a scan of a sheet of paper, but it can be enough for something of a size of an ID.
A photographic proof may be tested for authenticity by checking an old thumbnail and what was cropped out.
A photo with nakedness can be censored or cropped and then get popular over the Internet.

So what I'm missing here? It seems a serious security vulnerability, something at least a common user should be well aware of, and yet I wasn't. Microsoft answered on my e-mail:

  this is not a valid vulnerability as this is by design. This functionality is also inline with cropping in Office.

However I was aware of that in case of MS Office (still many users might not be), and if you print the document to either paper or PDF the cropped data is lost; you can also use the "compress" feature and remove cropped parts of an image there. How to you deal with JPG files, though?

Is there a tool to read old thumbnails of images?
How to remove data from an image permanently?
Is it just a single previous thumbnail or all previous thumbnails that are stored?
Does it affect only thumbnails, or - as MS suggests - it works like in Office and whole original photo is stored in a file?
Where can I read more about this issue/feature?

Jpeg files can contain Exif data, which can include a thumbnail. Theoretically, it seems it would be possible to store more than one, but I don't know of any program that does it, nor of a program that would read it.

What is likely to have happened in your case is that the program you used to crop the image modified only the main image, without modifying the embedded thumbnail.

exiftool can be used to read or replace Exif data, including the thumbnail. As show in the documentation, exiftool -b -ThumbnailImage image.jpg > thumbnail.jpg can be used to extract the thumbnail from a jpeg, exiftool '-ThumbnailImage<=thumb.jpg' dst.jpg to replace it. If you want to completely remove the embedded thumbnail, you could use exiftool -ThumbnailImage= dst.jpg.

Note that exif data can contain much more than a thumbnail, as exiftool -a -u -g1 a.jpg will show you.


Why is there a "show password" functionality in some login forms? I've noticed that on a lot of login forms in websites and applications that there is a "show password" check box. Why? I myself have seen some hacks that an attacker could hack the input password box. Doesn't enabling the "show password" box constitute as a security risk?

The 'show password' option is a feature designed for better user experience. This started getting popular with the recent rise in numbers of mobile devices. The small on screen keyboards are notoriously difficult to type with, and when you are unable to see your input it can make it difficult to be sure the password was typed correctly.

I am not sure of any attacks that target readable password fields. In my opinion, if you have malware on your computer that can see your screen, then its quite probable they are capturing your keystrokes as well.

Is it a risk? Yes. This should never be the default behavior, but if a user feels they are comfortable displaying their password (secure in their physical envirioment), then I see no problem with this practice.

This is just my opinion, not a rule.


Forcepoint secure email I just got an email from a financial institution in answer to a question I raised with them. It came in the form of a "secure email" from Forcepoint, which requires you to open an HTML document and click on a link contained within. The document has an encrypted block of code in it which I presume is used in the process of creating the link / communicating with the remote server.

The link then gave me a registration form to fill in including a password and security question. I generated a random password and bogus answer for this purpose as I would always do.

After that I got another link by email which gave me the answer to my original question.

The whole process had a bad smell to it, including the dodgy-looking domain names involved ("voltage-pp-0000.secure-mailcontrol.com" - really?).

What's the security advantage of this, if any? Requiring you to click on an attachment seems like a really bad idea. I only followed the instructions because the context was such that I knew it was very unlikely to be a phishing attempt and none of the information asked for would be of any use if it were.

Actually, the process is something like this. A customer would send an email to internal organization like opening an account or getting a loan etc. So, the organization would reply to the same email asking for sensitive information and necessary documents. When the outgoing email hits Forcepoint, it would encrypt and sends it to the customer outside of the organization. When the customer clicks on the link, it would prompt to create an account so, he/she can upload the necessary documents in the future. In this case, there is no client side validation for the first time because, there is no sensitive information sent from organization's end (atleast, thats the usual process). This allows customers to send documents. But, for the second email, he/she have to login to access the documents uploaded lastime and that's how it authenticates the user. Yes, anyone who received an email can create a login and access the email(which only requests for information) but, it doesn't contain any sensitive information.


Limiting VPC subnet access for NAT OpenVPN clients I'm currently testing OpenVPN to give developers limited access to AWS VPC's.
Assuming I have 3 VPC's... VPC-A, VPC-B, VPC-C, each of these with private and public subnets.
The OpenVPN server will be in the public subnet VPC-A-Pub-1.
VPC-A is peered to the other 2 VPC's.
I want developers to have direct access to VPC-A, and VPC-B, but not VPC-C.
My openvpn server.conf
port 1194
proto udp
dev tun

ca ca.crt
cert server.crt
key server.key

dh dh2048.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

push "route 10.130.0.0 255.255.192.0" # VPC-A
push "route 10.131.0.0 255.255.192.0" # VPC-B

keepalive 10 120
auth SHA384
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
cipher AES-256-CBC
comp-lzo

persist-key
persist-tun

status /var/log/openvpn-status.log

log         /var/log/openvpn.log
verb 3
mute 20

plugin /usr/lib/openvpn/openvpn-auth-ldap.so /etc/openvpn/auth/auth-ldap.conf
client-cert-not-required

Just regarding the routes, 10.130.0.0, and 10.131.0.0 are for VPC-A and VPC-B.
Additionally, in the rc.local, I'm setting up nat like so...
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ens5 -j MASQUERADE

With this setup, I can now connect to resources in VPC-A, and VPC-B, but not VPC-C. However I'm just wondering if this is actually a safe way to do it. The routes are pushed to the client, but does that mean that the user could simply add an additional route at their end for 10.132.0.0, to give themselves access to VPC-C?
Is there a proper, secure way to ensure that VPN clients can never get to a particular VPC?

The routing problem sounds like something you could quickly prove by simply trying it out, although I imagine it will work. The routes pushed to the client are really just suggestions, and don't stop the user from adding other routes. If your server knows how to route the packets and there is nothing else preventing it from doing so, people can likely access VPC-C.
Assuming you have a valid case for the server to be peered with VPC-C at all, the correct solution would be to implement firewall rules on the server that prevent access to the VPC-C subnet from the VPN interface.


Getting started with biometric locks? I am not sure if this is the place to ask this question and if it is not, i would really appreciate it if you could direct me to the right place. I wanted to understand the functionality and the system behind biometric locking. I was wondering where i could begin and the different kind of bio signals or prints that could be used for it.

In a lock you have a key (in a normal lock it is an actual key) having some features (grooves, indentations, crenellations) that

are difficult (ideally impossible) to duplicate
are difficult (" ") to tamper with, and do not degrade/change with time
are easy to verify
generate a very large keyspace (reducing the feasibility of a brute force approach)
are cheap to make ;-)

In a biometric lock the key is a living organism (e.g. you), hence the bio- part, and the features are some measurements (hence the -metric) on said organism.

Several measurements can be taken from a human being, but when you check them out with the above checklist some difficulties pop out:

fingerprints are easy to duplicate
retinal image is complex to acquire
the voiceprint is prone to changes
muscle memory is again prone to changes
DNA scan is either slow, or not sufficiently accurate

Whenever a measurement is prone to changes, it needs either to be measured with great accuracy and multiple attempts (which becomes awkward), or the acceptance criteria need to be relaxed; and in that case the "keyspace" shrinks and the duplicability of the measurement may become easy (e.g. computer generated voice samples from recordings).

Mixing several measurements, also adding in the mix some that per se would not be reliable, can increase accuracy and reduce the vulnerability. For example a fingerprint reader could be equipped with unreliable sensors to verify:
 - the IR emission (passive) is that of a live human finger
 - the IR emission (passive) shows fluctuations at approximately the heartbeat frequency
 - the IR and visible reflectivity (active) are those of human flesh with nothing (such as a thin fingerprint-printed silicone layer) between sensor and flesh
 - dielectric characteristics are those of a human finger
 ...

The problem becomes then one of cost.

Once the "defense" sensors have given their okay, you run a feature extractor on the raw signal, and from the basic features and an average feature survey you can establish the information associated to each feature.

For a fingerprint, the "features" could be the presence and (relative) position of specific markings - ridges, whorls, loops and so on. For human voice, the spectral content of same. For muscle memory, the timings and precision of some well-known and repetitive task such as typing one's name on a keyboard. For DNA it could simply be a given DNA sequence (...ACTGATTTCAAC...). And so on.

Ultimately this yields a string of bits, which is the representation of the signal also "cleaned" of unwanted variations (in the fingerprint case, these would be caused by finger pressure, speed, alignment; in the DNA case we would look for a sequence between two easily recognized and unique 'marker' sequences, possibly amplified and reconstructed from several samples) and noise (in the finger's case, possibly dirt or sweat).

It is then a matter of searching a user database for the desired string. Finally this yields a basic information ("found" or "not found") and possibly a user identification ("Found: user ID 123456").


How could this SSO implementation possibly work without browser cookies? Our corporate Windows 7 desktop setup is now using SSO with our Confluence instance (browser-based wiki-type website) but the strangest thing is that even after logging out AND clearing the browser cookies (and everything else) I still remain signed-in!!??  This situation only happens when using Chrome.  With Firefox, when I log out (or clear cookies) I remain logged out.

When navigating to our Confluence URL, it first redirects to our corporate SSO domain, and then back to Confluence.  So, it's doing something to get my Windows credentials I guess, but I don't understand how it can sign me back in after I logged out of both the Confluence site AND the SSO site AND cleared cookies.  In fact, at this point, I cannot sign-out at all.

Is the behavior I described with the Chrome browser supposed to be happening and, if so, by what mechanism?

Probably your web applications and/or your corporate SSO was setup to use SPNEGO authentication, which is most times used with Kerberos. It then uses your Kerberos ticket granting ticket (TGT) you obtained during Windows logon to get service tickets for authenticating to a "kerberized" service.

In the Windows browser configuration there are options IIRC called "Integrated Authentication".

There's also a tool called kerbtray.exe which displays current content of your Windows session's ticket cache. If SPNEGO/Kerberos is used you will find service tickets for service principal names like HTTP/app.example.com@REALM.EXAMPLE.COM or similar.


Does DPAPI works if a user hasn't a login password? I was wondering if the DPAPI will still work properly if a user doesn't have a a login password (like most of the home users). I can't find this information on Google or in the official documentation and I can't test it because the computers at work can't be without a password.

Yes, but it's not quite as secure. DPAPI encrypts data with a master key, which is independent of the user password. When the user has a password, the master key is encrypted with the user's password. Without a password, an attacker with local access (via another user account) might extract the master key. However, once an attacker has local access to the system it's game over anyway. DPAPI is just a damage limitation system, really.


Would secure storing of past used/generated passwords be a good idea? Let's assume an organisation that generates ~100 Passwords a week; these Passwords are 32-Characters long and randomly generated. The consultants that need passwords generated use a Password-generator that

generates 20 Passwords upon request
the consultant then chooses one out of 20 suggestions

One requirement from our "security advisor" is to prevent generated-password-reuse, e.g. guarantee the uniqueness of each password. I'm asked to find a solution, and while I know that I would have to use bcrypt to store the hashes of each generated password I personally think this is a bad idea. An attacker that gets a hold on the ever-generated-pw-db (although just the hopefully secure hashes) has a nice dictionary.

Is there a solution on how to do this (store all generated passwords) securely?

is there one KILLER-argument (like rainbow-tables for simple hashing) to say that this solution is bad from a security POV?

Let's do mathematics. I like mathematics.

You generate passwords in a space of size n = 6232 (32 characters chosen randomly, uniformly and independently of each other, in an alphabet of size 62, i.e. all uppercase letters, lowercase letters, and digits). Suppose that you have generated k such passwords; k is easily estimated since you will produce about 2000 potential passwords per week (100 "true passwords" but each of them is chosen among 20 fresh random passwords).

It is easily seen that k will remain much smaller than the square root of n (indeed, k will be in the vicinity of the square root of n only after about 457 thousands of billions of billions of years). We can then approximate the probability that you ever obtain a collision (i.e. the same candidate password shows up twice) to be about k2/2n. Assuming that you keep your system going for a hundred years (which is already preposterous), i.e. about 5218 weeks, this yields the probability of close to 2.4·10-44.

Now compare that with the probability of your security advisor being mauled by a gorilla escaped from a zoo; that probability is at least 10-18 per day (I have made this comparison before, and then again because I love this example; and the actual probability is higher than that, but let's be conservative). Therefore, on average, before hitting a collision, your security advisor will be visited by at least 4.7·1025 murderous gorillas, i.e. 47 millions of billions of billions of gorillas (since that far exceeds the number of living gorillas, one has to assume that some of them will come several times). If the advisor still worries about the collision and not the gorillas, then you have demonstrated that this advisor is no smarter than a baboon.

To sum up, it is easy to ensure that no password is reused: the Universe already makes it so. By doing nothing special you are already ensuring this absence of collision, with a success rate which is billions (of billions) of times better than your success at protecting your security advisor (and his children) from gorilla attacks (and you are probably already doing a good job at that, too).

Now let's suppose that your security advisor is unmoved by mathematics, because he believes in pretty pictures more than in pretty figures (in that respect, he would be no different from the average chimpanzee, so at least there is some kind of ironic consistency here). Setting up a system to filter out "duplicates" would be a waste of money, and, crucially, a way which can be easily demonstrated (e.g. to the boss of that "security advisor") to be a waste of money (be sure to make him aware of that fact); however, he may still insist on it, because he suggested it first and reneging on his own past word would endanger his perceived alpha-male status (again, chimpanzees come to mind). This unfortunately happens a lot with humans. Then your job, after having duly warned your hierarchy of the complete inanity of it (leave written traces ! They will protect you when somebody with more than three brain cells does an audit), is to make sure that, at least, this duplicate-detection system does not weaken the system. The duplicate detection is wasteful; let it not be harmful.

The space of possible passwords is very large, a bit more than 2190. All passwords are equiprobable, so you have about 190 bits of entropy, which is huge. For such passwords you DON'T NEED good password hashing because all of the features of password hashing functions (salts, iterations...) are ways to cope with the inherent weakness of "normal" passwords, i.e. the fact that they have low entropy, and thus can be brute forced (this is called a dictionary attack). However, your passwords have way too much entropy for brute force to be even remotely applicable to them (even if you somehow hire the gorillas to try passwords, you will run out of gorillas much before you run out of possible passwords). Therefore, simple hashing would work: store the hash values in a database, which will allow you to do a fast "already used" check.

However, there are systems out there who "use passwords" by actually hashing them and using the hash value as "the passwords". Windows in particular: when it uses a password, it actually works over the MD4 hash value (128 bits) computed over the password. Therefore, if you store hashed passwords and happen to use the same hash function as some other password-consuming system, then you are actually storing "cleartext" passwords, and that's bad.

To avoid this problem, use "your own" hash function, which in practice means HMAC. The hashing process would look like this (in C#/.NET):

using System.Security.Cryptography;
using System.Text;

// ...
static byte[] hmacKey = Encoding.UTF8.GetBytes("my security advisor is a chimpanzee");

static byte[] HashPassword(string password)
{
    HMAC h = HMAC.Create();
    h.Key = hmacKey;
    return h.ComputeHash(Encoding.UTF8.GetBytes(password));
}

It is quite improbable that any other system out there uses the same password hashing function (i.e. HMAC with the same key), so storing these "hash" values in a database would be safe, and allow duplicate detection.

Now the killer argument: why, oh why, would you want to detect duplicates ? A system which detect duplicates is also, inherently, a system which can tell what passwords are (or have been) in use. Such a system can only harm security: it helps attacker know whether a given password is "worth trying" on a system. Fortunately, the sheer size of the space of possible passwords in your case voids that harm. However, in all generality, insisting on detecting duplicates is also insisting on weakening the protection offered by the passwords. This is bad, bordering on malicious.

It would be relatively easy to suggest, with some careful wording, that the security advisor is trying to plant a backdoor (of course, not a very good backdoor, because he is not good at it, but intent is what matters in criminal cases). For instance, consider the following setup: you design a system which helps users generate 4-digit PIN codes for their bank smart card. The smart card will block itself after three wrong PIN codes, so an attacker who steals the card has only probability 1/3333 to guess it. However, if there is a system which generates random PIN codes and avoids duplicates then the attacker could hijack that system (e.g. dump its database with some SQL injection attack) and then let it generate 9999 PIN codes, which will all, by construction, be different from the PIN code that the smart card user obtained. This reveals the user's PIN: it is the only one, among the 10000 possible PIN codes, that the anti-duplicate system will not generate.

That's the core of it: when preventing duplicates for passwords has any detectable effect (not your case here, because duplicates won't happen in your lifetime or even in the Sun's lifetime, for that matter), then that effect is negative. This is a BAD IDEA. It smells of foul play.


Is it secure to set default value for password field? I'm looking at an application where admins can "invite" users by email and invited users. Invited users then are sent a unique URL and are inserted into a MySQL database with status pending and an activation token.

However, the application has a bug currently, where the DB was set up with the password field NOT NULL, and without default value, which makes INSERTs fail.

If I modify my table structure and set a default value for the password (using some arbitrary encrypted value), admins can add new users and these users are prompted to set a password prior to first login.

My question is - is there a security risk here that I should be aware of?

Copied:
Is it secure to set default value for password field? - DBA StackExchage

If your hashing function is secure enough this shouldn't be a problem, even if an attacker know your default value he cannot in a reasonable time find a password hashing in your default value.

Anything that isn't the the result of your hashing function is a good default value (i still think you should use a random value and not your first pet name but both are ok).


Bruteforcing via port 88 on MacOS Macos has open port 88 by default. Is it possible to check validity of the password via this port from Linux and how?
If the vncserver is active, it is possible to know also the username (by connecting to it with vncviewer) what would make brute forcing easier.
Does openssh on macos has something built-in to prevent bruteforcing, assuming it is also enabled?

Yes, this is possible.

Kerberos runs on port 88 on macOS. Kerberos by default has no protections against brute forcing. Submitting an enormous volume of password authentication requests to Kerberos is possible, though to be honest such a thing is useless unless your password is incredibly poor. Kerberos does allow authentication against any user account on the machine so you should consider both the security of your account as well as all your users.

Kerberos is enabled on macOS when you enable File Sharing or VNC to facilitate automatic authentication using your Apple ID on other machines you own. It's a pretty nifty feature. That being said, you should not allow connections to Kerberos from outside your network


Developer Security Training .NET / JAVA Hello my team is tasked to perform security focused training for developers (.NET and JAVA). I have used WebGoat to demonstrate OWASP Top 10 type security vulnerabilities and am looking for a similar tools / software to for demo and labs to cover security focused topics in .NET and Java. The goal is to show insecure code and then how to write secure code

Any help is appreciated

Try this:
http://pentestlab.org/10-vulnerable-web-applications-you-can-play-with/

and this:
https://www.owasp.org/index.php/Appendix_A:_Testing_Tools

or just google for vulnerable web application for learning penetration testing.


What threats are mitigated in drives encrypted by USB-SATA bridge? Some external HDDs (notably, WD Essentials) are known to be encrypted by the USB-SATA bridge present in their case:

  Essentials drives are hardware encrypted. The USB-SATA bridge board is required to decrypt the data.

This is confirmed by users who are unable to access any data once the HDD is extracted from its external case and attached directly to SATA.

I don't quite understand what purpose this kind of encryption serves. If the drive is lost or stolen, so is (most probably) the external case, so data security is unaffected. If anything, this makes legitimate data recovery more difficult, if the said bridge board is damaged. Am I missing something?

Having the drive pre-encrypted with the key stored on the drive or controller makes it faster if they want to later properly encrypt it - you just encrypt the key with the password, rather than having to encrypt the whole drive.

This means it's a ten-second process rather than several hours.


Is it safe to use IP Addresses as an identity? I have a website where users can generate links. I'd like to limit 10 links to a user, but would also like to avoid requiring a login/email. I was thinking about using the IP Address as an identity system.

Is this a bad idea? I can see two possible issues:

Is it possible for a user to automatically generate IP addresses and fill my database with a ton of spam?
Is it possible for a user to spoof the IP address of another user, and gain access to their links.

Is it possible for a user to automatically generate ip addresses and fill my database with a ton of spam?

Usually no. As the ISP DHCP leasing mechanisms nowadays try to pin a specific IP to a specific user as long as possible. They would need a zombie botnet of other people's computer to flood your system this way.

  Is it possible for a user to spoof the ip address of another user, and gain access to their links.

Generally yes. Whilst IP spoofing has been made somewhat harder, depending on the protocol; you should assume the IP is not secure or consistent. Besides, users themselve often do not have static IPs

Overall, don't use an IP as the sole source of identity if you can think of other methods.

To avoid using a login you could simply cache their identity in a long term browser cookie or Flash LSO. Users that purge out LSOs (a minority) could get more links by "resetting" their identity (much like newspaper soft-paywalls) - but this depends on how important limiting users to 10 links is for your website.


Best email SPF practice for dispersed users? I am the sysadmin for my church. Our church has our own domain website and email hosted externally. We have about 50 members or so who use their church email from home. I am just looking for best practices that I can employ in our DNS to help control things like spam and email spoofing better?

For sending:

1) How can SPF be utilized best when these users are sending emails through another MTA, which is usually the case as they all have their own ISP at home? If I setup SPF for our domain there is only a handful of ISP's where I live so I suppose one approach that I could take is including the ISP MTA in the record. But is there a better way to use SPF so when they send as @churchdomain from home a receiving SPF implementation does not reject?

For receiving:

2) For our users receiving emails at @churchdomain at their home is there anything I can do outside of tweaking our email hosting providers spam settings to filter email? IIRC setting up SPF on the church domain would only help with the sending aspect.

Any insights or help is greatly appreciated.

How can SPF be utilized best when these users are sending emails through another MTA, which is usually the case as they all have their own ISP at home?

The usual setup of an user facing MTA today requires authentication by the user and often restricts the user to only use the email connected to the authorized user account as sender. This means that users don't use a single MTA for multiple sender addresses but use a separate MTA for each sender address. For example a user connected via some ISP X would still use smtp.gmail.com for delivering mail with its gmail account as sender.

This means that you have to do the same as all the other mail providers: setup your MTA, require authentication and allow only authorized users to send mail with the sender address associated with their user account. Once this is done all outgoing mail from your domain will originate from your mail server and you could easily employ restricted SPF records and also DKIM signatures.

  For receiving: ...

While you can add SPF, DKIM and other anti spam checks to incoming mail your own SPF settings do not matter at all in this case.


How to detect the "Hello packets" sent by a wifi enabled smartphone Actually I have a case where I should able to detect the mobile phones and get some data about the device available in my network range without connecting to the network.

I have seen somewhere that a smart-phone continuously transmits hello packets so that we can detect that device when it comes in our network.

Can a smart-phone send hello packets continuously?
if so.. how can we detect them and get some data about that device?

I believe spartan is talking about Wifi "probe requests".  You can capture these using wireshark when your wireless adapter is set to "monitor mode".

You can filter for them using the following syntax:

wlan.fc.type_subtype == 0x04

These are managment frames and are basically frames sent from your client to find out which wireless networks / AP are around.

More information can be found on Hak5's episode on probe requests.

If you are talking about these other "hello packets", such as automatic pings or so, then Wireshark is still your friend.


How to implement encryption/decryption system using IV between mobile app and web service In my app we are going to send encrypted data to the web service. I am using the following code to encrypt and decrypt the data -

public class DecEn {
    private static final String password = "test";
    private static String salt;
    private static int pswdIterations = 65536;
    private static int keySize = 256;
    private byte[] ivBytes;

    public String encrypt(String plainText) throws Exception {

        //get salt
        salt = generateSalt();
        byte[] saltBytes = salt.getBytes("UTF-8");

        // Derive the key
        SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
        PBEKeySpec spec = new PBEKeySpec(
                password.toCharArray(),
                saltBytes,
                pswdIterations,
                keySize
        );

        SecretKey secretKey = factory.generateSecret(spec);
        SecretKeySpec secret = new SecretKeySpec(secretKey.getEncoded(), "AES");

        //encrypt the message
        Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
        cipher.init(Cipher.ENCRYPT_MODE, secret);
        AlgorithmParameters params = cipher.getParameters();
        ivBytes = params.getParameterSpec(IvParameterSpec.class).getIV();
        byte[] encryptedTextBytes = cipher.doFinal(plainText.getBytes("UTF-8"));
        return new Base64().encodeAsString(encryptedTextBytes);
//      return Base64.encodeBase64String(encryptedTextBytes);
//      return Hex.encodeHexString(encryptedTextBytes);
    }

    @SuppressWarnings("static-access")
    public String decrypt(String encryptedText) throws Exception {

        byte[] saltBytes = salt.getBytes("UTF-8");
        byte[] encryptedTextBytes = new Base64().decodeBase64(encryptedText);
//      byte[] encryptedTextBytes = Base64.decodeBase64(encryptedText);
//      byte[] encryptedTextBytes = Hex.decodeHex(encryptedText.toCharArray());

        // Derive the key
        SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
        PBEKeySpec spec = new PBEKeySpec(
                password.toCharArray(),
                saltBytes,
                pswdIterations,
                keySize
        );

        SecretKey secretKey = factory.generateSecret(spec);
        SecretKeySpec secret = new SecretKeySpec(secretKey.getEncoded(), "AES");

        // Decrypt the message
        Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
        cipher.init(Cipher.DECRYPT_MODE, secret, new IvParameterSpec(ivBytes));

        byte[] decryptedTextBytes = null;
        try {
            decryptedTextBytes = cipher.doFinal(encryptedTextBytes);
        } catch (IllegalBlockSizeException e) {
            e.printStackTrace();
        } catch (BadPaddingException e) {
            e.printStackTrace();
        }

        return new String(decryptedTextBytes);
    }

    public String generateSalt() {
        SecureRandom random = new SecureRandom();
        byte bytes[] = new byte[20];
        random.nextBytes(bytes);
        String s = new String(bytes);
        return s;
    }
}

The above code stores IV and salt after they are generated and reuses them to decrypt the data. This will not be true in case of collaboration between app and web service.
What I am actually confused about is that IV and salt are being generated anew each time data is encrypted which is the recommended procedure as far as I could tell from my Googling but as this data is being sent to a web service the IV and the salt has to be available there which means I will have to send it along with my data. Doesn't this defeat the purpose of encryption? As it makes the information available to the attacker.
Or the other way seems to be to use static IV and salt which again makes the encryption susceptible to attacks. That encryption is being used successfully world wide indicates that my understanding of the subject is lacking somewhere.
Please help me by clearing up my doubts.

Initialization vectors aren't meant to be private. The goal of an IV isn't to strengthen the key but to make sure that no two identical (or similar) clear text will result in the same (or similar) cipher text.

It works like this: AES (along with most - but not all - modern crypto algorithm) is a block cipher. It only operate on a fixed amount of data (in AES case, 128 bits). So, in order for identical data blocks within the source data (i.e. using the same key) to be identical, it is usual to specify a mode of operation that introduce some form of change between two data blocks.

In your case, you've selected CBC which basically XOR the clear text of the block N with the cipher text of block N-1 before encrypting it.

This works well except for the first block: there is no previous block to mix it with and therefore, if you don't do something about it, if the clear text starts with the same 128 bits will be similar if the same key is used for encryption. This is a real problem because it is quite frequent for two messages to have the same first 128 bits. Furthermore, depending on the application, it is possible to deduce the meaning of the message without even decrypting it (think of "yes" and "no" answers, for instances).

That what the IV is for: it makes sure that, as long as you don't reuse the IV, you won't have to worry about two messages yielding identical clear text.

Another point worth making is that you could do the same with changing the key. There is two problems here:

Key are often picked up on the fly and therefore only statistically unique (which isn't a problem).
Key are expensive to change: at best, you need to re-negociate a key (for instance, with DH). At worth, you need to re-create a new key and exchange it through a secure channel.


Encrypting something with multiple keys such that k out of n keys are needed; what's it called? I am trying to find information on how to encrypt something in such a way that there are n keys, and k of them are needed for decryption. However, I have been searching Google for half an hour but because I do not know what this is called (and am apparently bad at searching), I cannot find it.

EDIT: preferably such that the keys can be chosen, if this exists under a special name.

To complete @Terry's answer:

Shamir's secret sharing works on values in a given field (the mathematical concept). In practice, if you accept that you won't make more than 255 shares (i.e. 1 < k ≤ n ≤ 255) then it is convenient to work in GF(256), the field with 256 elements. This would mean that you actually do the sharing on each byte independently of the others, and thus that you can "share" any secret which fits in a sequence of bytes (so, really, anything which fits in a computer). And it is quite efficient.

Since each share has the same length as the secret data, you may want to optimize things a bit with encryption. This means that if you want to share a big secret value S (e.g. a 3 gigabytes video), then you:

Create a random 128-bit key K.
Encrypt S with K and a good symmetric cipher; the encrypted value is stored in a common area where every participant can retrieve it.
Applies Shamir's secret sharing on K.

This way, each share holder only has to remember something which is the size of K (16 bytes, easily fits in various places, e.g. a smartcard or even a human brain), while the secret value S can be arbitrarily large and efficiently stored and distributed (since it is encrypted, it can be shown to the public at large, e.g. transferred with a peer-to-peer network).

Now for the choosing the share values, that's an interesting problem. If you have n shares and a threshold of k, the normal description of Shamir's scheme implies that each share is essentially random. The secret splitting outputs the shares, and the share holders can only get them.

The computations can be trivially extended into a scheme where at most k-1 shares are chosen arbitrarily. So some shares must still be random.

User-chosen shares make sense when shares must be remembered, i.e. are passwords. But passwords are subject to brute force. For instance, if an attacker obtained k-1 shares and knows that one of the other shares is a password, then he can run a dictionary attack on that extra share, namely trying out potential passwords (for each password, recomputing the shared secret with that password as extra share, and see if the result "makes sense"). This unfortunately weakens the whole system.

Indeed, a great property of Shamir's scheme is that it is unconditionally secure, meaning that it resists attackers with arbitrary computing power, including computers which have not been invented yet (as long as the source of randomness used in the splitting is really random). This simplifies security analysis, in particular for long-term storage, where you have to predict how much computing power attackers will have decades from now. But if you insert passwords in the mix, this unconditional security vaporizes as dew under the morning Sun.


What does it mean that Ikev1 (IPSec) protects peer identities in main mode? Does it mean that the source IP is replaced with something else (like if in IP spoofing) so intermediate routers don't know who is sending the packet?

Identity here does not have anything to do with peer IP addresses, which indeed are both visible for anyone along the route. Instead, the identity refers to public keys, as they would identify the peers. From IKEv1 (obsoleted by IKEv2, RFC 7296) Phase 1 Authenticated With Public Key Encryption, RFC 2409, 5.2:

In order to perform the public key encryption, the initiator must
already have the responder's public key. In the case where the
responder has multiple public keys, a hash of the certificate the
initiator is using to encrypt the ancillary information is passed as
part of the third message. In this way the responder can determine
which corresponding private key to use to decrypt the encrypted
payloads and identity protection is retained.
In addition to the nonce, the identities of the parties (IDii and
IDir) are also encrypted with the other party's public key.

The identity protection means that anyone eavesdropping the connection cannot tell anything about the public keys of the peers. Therefore, they only have the IP addresses, but not the identities.


gpg agent and caching symmetric encryption passphrase for writing With public-key encryption, one can encrypt and decrypt a file repeatedly if gpg-agent caches the passphrase for the key. However, with symmetric encryption I'm always prompted for the passphrase when encrypting even if gpg-agent obviously has the passphrase cached because I'm not prompted when decrypting.

This is related to gpg2 --symmetric and passphrase, but there the OP wants to be prompted always, here I want to be never prompted. Can gpg/gpg-agent be configured to do that?

I also wanted to do this (with symmetric encryption, no keys) and Xen2050's mention of gpg-preset-passphrase was helpful, but I still was stuck on how to derive the correct cacheid to use with gpg-preset-passphrase to associate the passphrase with the encrypted file.

tl;dr the cacheid is the 8-octet hex-encoded s2k salt randomly chosen on encryption, prefixed with the letter "S", e.g. S0123456789ABCDEF:

/path/to/gpg-preset-passphrase --preset S0123456789ABCDEF <<EOF
$PASSPHRASE
EOF

See this detailed answer for instructions on encrypting, getting the cacheid, presetting, and decrypting with passphrase from variable (no prompts at all): https://superuser.com/a/1485486/1093343


How long should the maximum password length be? The minimum password length recommended is about 8 characters, so is there any standard/recommended maximum length of the password?

The answer to this one, like a lot of questions in Security is "it depends".

There's several factors to consider when looking at password length. First up is some of the things that a long password is designed to protect against, which is generally a brute-force of password guessing attack (online or offline).

For online password guessing, if you've got a relatively aggresive lockout policy (eg, 3 incorrect attempts and then an indefinate lockout) then attacks against a single account will be unlikely to succeed unless the attacker has a good idea of what the password is going to be.

If you're looking against attacks on a large population of users with the same lockout policy, where the attacker can work out the usernames (eg web forums), then the most important element is probably that the passwords used aren't any of the really common ones.

As an aside,  one thing to watch for on the account lockout side, is that aggresive policies here for on-line applications can make a Denial of service attack quite easy, without additional countermeasures.

If there's a risk of offline brute force then password strength becomes more important.  the problem here is that improved processing power and methods of attack make this a moving target in terms of strength.  Realistically I'd say that you'd be looking at 10+ characters and strong enforcement that passwords aren't on common dictionary lists (like @andy says passphrases are a good option here).

Another factor to consider here is your user base, and how the application is used.  In some cases, I'd say that very strong password requirements can actually lead to a less secure application.  If you have an application where the users are in the same place (eg, a lot of corporate applications) and you make the password policy very "strong" (both in terms of password length and rotation requirements) then it's likely that users will start writing down their passwords, which probably defeats one of the goals of security for that application in the first place.

One good source of a lot more information on this is a book called Authentication: From Passwords to Public Keys


Vulnerable framework and IIS server version's are being displayed in an error page of a 3rd party application As security tester, I need to report and justify that a security misconfiguration in a 3rd party application is a risk to us.

Following is the scenario:

1.)  There is a 3rd party application which the customers use to submit their applications to us. We receive the data from the 3rd party application and process them further.

2.)  In that particular application, upon clicking a hyperlink an error page is being displayed with the following information:

a) Source file path (however it is forbidden when tried to access)
b) .Net framework version which is vulnerable ASP.Net Forms Authentication Bypass
c) IIS server version (7.5) which has exploits as per my knowledge.

What is the risk of this misconfiguration to us. How to justify it?

Note: This error page appears only after a user is logged in. And this is a public facing application.

The source file path is not necessarily an issue. However it is bad practice and leaks information that may be useful for exploiting other issues.

  IIS server version (7.5) which has exploits as per my knowledge.

IIS 7.5 is still under Extended Support until 2020. This means it should receive security updates - so this isn't necessarily an issue. You would need to request the patch history from the 3rd party.

  .Net framework version which is vulnerable ASP.Net Forms Authentication Bypass

Again this was patched. A version number alone means nothing.

  What is the risk of this misconfiguration to us. How to justify it?

What exactly is it your clients submit to you? If it is there application executables are these distributed publicly? Or are they server side applications? And are they signed?

The biggest security risk I can see would be if someone patched a flaw in the application before submitting it to yourselves. Hence the client would have a vulnerability which you would not be able to make them aware of.


Icons/Symbols according to GDPR According to Article 12(7) of the European General Data Protection Regulation 2016/679 there shall be standard icons for making data collection more transparent for data subjects (end users):

  The information to be provided to data subjects pursuant to
  Articles 13 and 14 may be provided in combination with standardised
  icons in order to give in an easily visible, intelligible and clearly
  legible manner a meaningful overview of the intended processing. Where
  the icons are presented electronically they shall be machine-readable.

With 12(8) the EC is empowered to make the decision making, and with Article 7 (1r) The (new) European Data Protection Board is asked to provide input in this process. The EC must present the delegated act to EP and Council and only if they do not object within 3 month this can go into effect.

As the EDP Board is not yet formed and the (old) Article 29 Working Party currently seems not to work on the icon sets, I wonder if anybody already knows about work in progress or a roadmap. Will the EC start this process, if so what feed to follow to be informed about it?

Maybe you're just looking for the best RSS feeds for the latest info? In that case consider https://packetstormsecurity.com/feeds

More specifically, for your needs, I recommend following:

https://rss.packetstormsecurity.com/news/tags/goverment/
https://rss.packetstormsecurity.com/news/

Or just follow http://world.einnews.com/news/europe-security 's RSS feed.

EDUT: In regard to the first part of your Q - I do not know about the proceedings. I just gave you a list of feeds to follow if you'd like to stay updated. If anyone is able to give you a better answer, pick the other one.


OpenSSL with AES-256-CTR cipher I have installed OpenSSL on my OS X box and it provides the AES-256-CTR cipher. When I install OpenSSL on Windows, then the AES-256-CTR cipher isn't available. Can anyone explain why there is a difference?

I need the AES-CTR cipher, because it works with different blocks than AES-CBC...

AES-CTR-256 is only available since OpenSSL v1.0.1. It's possible to view the encoding ciphers by issueing the following command

openssl enc help

It will show all the available encoding ciphers. To check the current version of OpenSSL run the following command

openssl version

Note that the 0.9.8, 1.0.0 and 1.0.1 branches have been maintained in parallel. OpenSSL 0.9.8zc might be newer than 1.0.1e, so focus on the version instead of the date.

Some applications (i.e. Ruby) don't use the openssl executable, but link to libssl instead and inherit the abilities of the library. Upgrading OpenSSL to a newer version doesn't help much in that case. If the application uses dynamic linking, then it might suffice to upgrade libssl to a newer version. If it's linked statically, then the entire application needs to be recompiled with a newer libssl (or you might check if there is a newer version).

Ruby programmer's can check which OpenSSL version is installed by issueing the following command

ruby -ropenssl -e 'puts OpenSSL::OPENSSL_VERSION'


How can I secure keys for stored data in a Python web application against server side breach? I'm building a REST application to store credentials -- GitHub keys and other sensitive data (which may be uploaded by web app user). I'm looking for an optimal way to secure the data but I'm lost at how to lower the security risk in case the database/web application server is compromised.

Currently I'm looking at the following solution:

Encrypted credentials are stored in the application database.
Encryption keys for the credentials are stored in a separate database behind a firewall.
This, as I look at it, should reduce the risk if the application database is compromised.

Database is PostgreSQL and the server is likely to be Apache2+wsgi.

Does this architecture make sense? Is it redundant? What can be improved as to the storage of the encryption keys? What tools would you recommend for this use case? Thanks in advance!

The key to answering this question lies in thinking about what access your main web application has and what could happen if an attacker were able to re-program it to do whatever they like.

This thought experiment quickly shows the only way to completely prevent the sensitive data being leaked in this scenario is for the web application to never see it, for example by encrypting it on the client with a key known only by the client. This approach is often impractical for web applications.  However it is used for some applications such as cloud backups.

However, all is not lost.  One can still dramatically reduce the risks of a bulk loss of all of the sensitive data in the system in a couple of ways.

1. Store the encrypted data, but do not store the keys.

In the event of the server being compromised, the attacker only gets the encrypted data.  In normal operation the key can be supplied by the user - for example as their password.  This has the disadvantage that if a user loses their password, they also lose their data.

2. Place the sensitive data (or keys) on a separate server, behind a firewall accessible only via a restrictive API.

The key to this approach is to design the restrictive API such that if an attacker gains access to call it by compromising the main web application, they are limited in what they can retrieve. There are many ways to achieve this, but the basic ideas are as for any service.  Here are some of the things to consider if implementing such an API:

Require authentication (as the relevant end-user)
Don't provide bulk export APIs
Keep the API simple to reduce the risk of programming errors
Rate limit requests


Personal Google search history appeared on work computer. Does this mean work can see my private search history from my personal iPhone? I was recently using my personal google account on my work computer and some of my previous google searches appeared from my personal phone. I used Safari on my personal iPhone and I guess google.
So can work see that search history on my personal phone?
Maybe my google account was synced but I can’t access gmail on my work computer so I’m not sure why this showed up. Can they see my private searches or is it just pre filling from past searches from my private phone? Surely they cant access this from my private phone and it’s just google syncing somehow? I never used the work computer to search.

No, your work would have no ability to see the contents of your personal Google account. Someone walking by or if the computer has screen monitoring software would see what you saw on the screen.


How to Ensure Post Data in Services is Safe from User Tampering In WebGL Games? We are currently making WebGL games for an online portal that then rewards users points they get from In Game Score. The Score is sent to the WebServer in the form of POST service, Recently we have had cases where user Tamper with the score somehow. Any Idea on how to secure something like this? What are the standard Industry Practices for something like this. How Can we validate the scores on the Server?
Any Help would be greatly appreciated.

What are the standard Industry Practices for something like this. How
  Can we validate the scores on the Server?

It depends how tech-savvy your users are. A trivial way for them to tamper the data is to use a (intercepting) proxy to intercept outgoing traffic and tamper the Score value (TLS cannot prevent this).

One of the industry practices to prevent tampering and verify the authenticity of the requests is to use JWT. JWT is widely used for authentications management of REST APIs, however, it could also help to solve your problem. JWT signs all the requests and any modification of the data in transit would invalidate it on the server.

Remember, as I mentioned above it depends how technical your users are. Using JWT only stops tampering of the requests when they depart from your application. With a rare likelihood, a user can still directly access to the memory and modify something (e.g., change a game functionality, overwrite an attribute etc).


Is it possible to reverse a MySQL5.0 password hash? I was recently doing a penetration testing challenge and was able to extract the password hash of the remote user. I tried cracking the password using john the ripper and hashcat but both failed.

Long story short, is it possible to reverse a hashed MySQL5 password by any method other than brute forcing?

Welcome to Security.SE.

First, a brief explanation of hashing versus encryption, because that's important here.

Hashing and encryption

When talking about hashes, it is impossible to decrypt. Hashes are one-way and cannot be reversed to retrieve the plaintext. This matters because how you go about getting the plaintext is very different from encryption and hashing.

Finding the plaintext of a hash

John the Ripper and hashcat are both tools that can be used to find the plaintext of a hash. However, throwing a wordlist at them isn't always the most effective way to use those tools. You need to know a few things about the target, in addition to the algorithm used. You know you have a MySQL 5 hash, but here's some other things that will help you:

Is there a password policy? (minimum x characters, upper, lower, symbols, etc.)
If the administrator chose a common password, it may be in password lists. If the administrator did not, you may have to do additional reconnaissance to build a wordlist that is more directed at the user.

Is there another way besides brute forcing?

Short of a weakness in the algorithm itself, no. Hashes in general are intended to be resistant to attacks against the algorithm. While tools like John and Hashcat do try to make performance improvements against a particular algorithm given its properties, brute forcing, with keeping in mind what I mentioned above, is how hashes, MySQL hashes or otherwise, are attacked.

However, if you pulled a hash from a database in the challenge, that's different from pulling the MySQL user hash. That is, storing website users in a database doesn't necessarily use the MySQL hashing algorithm. It can be something else like MD5 or SHA1.


secure user authertication Here : Help understanding basic user authentication with salts and hashing

They explain it pretty well, but i'm still struggling to understand this one part...

  Now, when a user comes to log in again they submit their username and
  password in the form. You then want to see if they are in the table so
  you then:

  1) Look up the supplied username in your database and return the hash and
  the salt

  2) Take the provided username and rerun the hashing function
  using the salt obtained in 1 to do somehting like hash(salt+password
  submit on form)

  3) If the hash generated in 2, matches the on retrieved
  from the database in 1 then you know they provided the correct
  password

Does the client side of the application make the stored hash(pw+salt), send it over ssl/tls to the server and then check if it matches the one stroed on server ? if so , how do we get the salt ? Is it okay to send it from server to client in plain text over ssl/tls ?

Or do we send the password from client-side to server in plain text over ssl/tls and then generate the hash(pw+salt) on server-side whereafter we'd check if it matches ?

The client send the password to the server.

On registration the server creates the salt and stores it. It then computes and stores the password hash.

On login the client send the password again, the server looks up the salt in its own database, and computes the password hash for verification.