I have two places (as the product owner)
New feedback from customers can translate in more stories, a change of story priorities or some new details about a story. In the back log I take notes of these details for future stories that I might forget otherwise. These are notes for myself.
Shortly before the planning meeting, I translate what is in my head + these notes into something the team can review. This document (we use a wiki page per user epic) is further refined & completed during sprint planning as a part of discussing the story with the team.
Just make a new story for your new requirement.
The question in your title may not have a generic answer, but let's consider your example:
As a user I want to maintain a user profile
Suppose you had a definition of done for this story, including the ability to edit and save the home address, telephone number, and a few other things. The Product Owner agreed, the story was estimated and pulled into sprint. Later it was marked as done and the story points were earned.
If you change this story, this will induce a scope change of the original story. It also shows a drop in your burndown, even while you delivered high-quality work as was agreed upon before taking it up. See this related question. Make a new story, accept that it's tiny, and pull it in when you need to fill up your sprint with something small.
Learn from this, and adjust your definition of done each iteration so that it includes a once-over before the end, to prevent trivial additions before it's too late.
Best Answer
To be honest, after spending close to two years immersed in Agile development, I still think "user story" is just a fancy term for "functional requirement".
It's different at a superficial level, e.g. it always takes a certain form ("as an X, I want Y so that Z..."), but the key elements - identifying the stakeholder and the rationale - are also inherent in well-written functional requirements. It's just as easy to write a bad user story as it is to write a bad requirement ("as [our company name], I want [vague feature] so that I can [do something that's self-evidently part of my job, like 'sell more to customers']").
What user stories almost never capture, in my experience, are non-functional requirements like performance and security. These kinds of requirements are very difficult to write properly and the format of the user story simply isn't very good for capturing them, because they're more about general product quality and mitigating (but not eliminating) risks rather than meeting a specific user's need.
So, I really think of user stories as a subset of requirements, with a specific formula, and still use the terms pretty much interchangeably.
The one major advantage user stories do have over requirements is that the word "requirement" suggests that a feature is required where it is often just desired. User stories can in theory be prioritized and slotted in for any release, whereas requirements appear to be a prerequisite for every release.
Of course, for the aforementioned distinction to matter, your customers and/or senior management must embrace it; it does you no good whatsoever if you have 30 user stories all grouped into a "project" that must all be completed at the same time. You might as well call them "requirements" in that case because they are in fact required.