Estimates are Estimates
The purpose of estimating tasks, or stories, is to get an approximate mapping between "time spent" and "work done", which of course is mostly about answering the question "Will this piece of work get done by this deadline?"
However, it's really important to remember that estimates - whether they're done in actual time increments, or in story points, or in T-shirt sizes, or whatever - are estimates of the complexity of the task based on the knowledge of the people doing the estimation, at the time they produce the estimates. An experienced developer may look at a task and already have all the knowledge he needs to estimate it accurately, while a junior developer will potentially need to factor in a larger analysis - and, as you've noted, they may discover things during that analysis that affects their understanding of the task in a way that changes their estimate.
This is a good thing. It represents learning, and a growing knowledge within the team. It means that the next time the task comes up, the junior developer is better equipped to handle it, and will estimate it more accurately.
Ultimately, you want the estimates to stabilise as the team gains experience, so that while an individual task may not always live up to its estimate the work as a whole progresses at about the predicted pace, i.e. the team achieves a stable velocity.
Estimates can be revised
This should go without saying, but if information comes in that changes the understanding of a task then you shouldn't sweep it under the rug. Does the quick-and-simple solution introduce security risks? Then the team should be reviewing those risks and determine their impact on the scope of the task. It could mean breaking the task up to better reflect its new-found complexity, or it could mean de-prioritising the work until the security implications are better understood, or it could mean raising the priority and/or profile of the work to ensure that the security risks are appropriately treated and mitigated rather than left to fester (and if your team has a charter, or a similar agreement, you may want to include something in it about the relative priority of work - e.g. focus on delivering a stable, secure product over adding new features).
Agile Work is Team Effort
It is very easy to fall into the trap of thinking that since the senior developer can do everything faster, that they should be given all the critical work. This can be good for getting things done in the short term, but it is bad for the team in the long run.
Part of estimating the effort of a development team should include estimating the development of the team's skills to make them better able to handle work in the future, even in the face of uncertainty. This means incorporating time for training and learning - either as explicit tasks that form part of completing the work, or by reducing the team's anticipated velocity to account for the short-term efficiency loss. But it also means considering ways of better leveraging the team dynamics to make this happen faster.
Pair Programming (or just "pairing") is a practice where two developers are assigned to the same task to work on simultaneously. There are a lot of different arrangements, but one common one is to pair experienced and junior developers together and have them take turns writing code while the other watches and either learns or provides feedback. In your example, this means that the 15-minutes-for-the-expert-but-24-hours-for-the-newbie task will probably take some amount of time in between the two estimates, but it results in the junior developer having the knowledge that would have otherwise taken them days to acquire.
Communication is a Core Agile Practice
Possibly the most important point that seems to be missing from your example is the communication that happens in the team. There's a task on the backlog, and your junior developer is giving it a 2-hour estimate (that they later revise upwards) while your senior developer is giving a 15-minute estimate. This should absolutely be something that comes up in your stand-up, and is an opportunity for the senior developer to help the junior developer to study up on the system and for them to both gain an understanding of the other's perspective.
It could also be the case that the junior developer learns something that the senior developer - or the rest of the team - doesn't know, which is an opportunity for them to share this info with the team to lift everyone's abilities.
It's important, though, that the team has the right environment to enable this. Openness and Courage are two of the driving principles in Scrum, but they apply to any Agile team (or any good team, really). Your junior developer should feel empowered to come to stand-up and say "I'm working on task X, I've read up on it and I'm concerned about the security implications. I think it's going to take me another day to feel confident with dealing with them.".
transfer of learning. e.g. if you know one language well you just need an extensive overview of another similar language to get started.