{"action":"created","issue":{"url":"https://api.github.com/repos/symfony/symfony/issues/13988","labels_url":"https://api.github.com/repos/symfony/symfony/issues/13988/labels{/name}","comments_url":"https://api.github.com/repos/symfony/symfony/issues/13988/comments","events_url":"https://api.github.com/repos/symfony/symfony/issues/13988/events","html_url":"https://github.com/symfony/symfony/issues/13988","id":63093072,"number":13988,"title":"[SecurityBundle] UserPasswordEncoderCommand concerns","user":{"login":"ogizanagi","id":2211145,"avatar_url":"https://avatars.githubusercontent.com/u/2211145?v=3","gravatar_id":"","url":"https://api.github.com/users/ogizanagi","html_url":"https://github.com/ogizanagi","followers_url":"https://api.github.com/users/ogizanagi/followers","following_url":"https://api.github.com/users/ogizanagi/following{/other_user}","gists_url":"https://api.github.com/users/ogizanagi/gists{/gist_id}","starred_url":"https://api.github.com/users/ogizanagi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ogizanagi/subscriptions","organizations_url":"https://api.github.com/users/ogizanagi/orgs","repos_url":"https://api.github.com/users/ogizanagi/repos","events_url":"https://api.github.com/users/ogizanagi/events{/privacy}","received_events_url":"https://api.github.com/users/ogizanagi/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/symfony/symfony/labels/Security","name":"Security","color":"DDDDDD"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":33,"created_at":"2015-03-19T21:20:59Z","updated_at":"2015-03-23T16:06:18Z","closed_at":null,"body":"As I just tried it now, I've some concerns about the newly introduced command to encode user password (#12818).\r\n\r\n# Arguments order\r\n\r\nThe command currently looks like : \r\n\r\n```\r\nsecurity:encode-password [password] [user-class] [salt]\r\n```\r\n\r\nAll arguments are optional, for the interactive command purpose (The command will ask the user for missing arguments in a very user-friendly way).\r\nBut, as they are arguments, we should provide each of them in the proper order. That means we cannot provide a salt without defining the optional `user-class`.\r\n\r\nWhy not using options instead of arguments for both `user-class` & `salt` ?\r\n\r\n# Empty salt\r\n\r\nCurrently, the only way to generate a password with an empty salt (for `in_memory` users for example, or bcrypt) is by executing the following trick:\r\n```\r\nsecurity:encode-password p@ssw0rd --no-interaction.\r\n```\r\n\r\nIndeed, with interaction, if no salt or an empty salt is provided (`security:encode-password p@ssw0rd 'Symfony\\Component\\Security\\Core\\User\\User' ''`), we'll be asked for a salt. Then again, if we provide an empty salt (press enter), a salt is automatically generated.\r\n\r\n**Solutions (one of those):**\r\n- a new `--empty-salt` option\r\n- ask confirmation about providing or generating a salt\r\n- do not ask for salt if an empty salt is provided (`security:encode-password p@ssw0rd 'Symfony\\Component\\Security\\Core\\User\\User' ''`)\r\n\r\n# Symfony Core User should be the default user-class\r\n\r\nAs @jeremyFreeAgent said:\r\n> Since we configure Symfony\\Component\\Security\\Core\\User\\User in the setAutocompleterValues and set the $value to Symfony\\Component\\Security\\Core\\User\\User if null, I guess we can configure the default value of the user-class.\r\n\r\nIndeed, why not providing the `Symfony\\Component\\Security\\Core\\User\\User` as the default value of the `user-class` option/argument ?\r\nAsking it explicitly to the user is only useful for new symfony's users. Once understood, I think most users will provide it directly, or expect the default `Symfony\\Component\\Security\\Core\\User\\User` value.\r\n\r\n# Non interactive salt generation\r\n\r\nI see 2 \"issues\" here:\r\n- We cannot ask for a generated salt with non-interactive usage\r\n- Anyway, the salt isn't in the Table summarizing the generation.\r\n\r\n**Solution**\r\n- add a `--generate-salt` option in order to generate the salt instead of providing it\r\n- add the generated salt to the Table output\r\n\r\n\r\n=========\r\n\r\nWhat do you think ?\r\n\r\nping @saro0h"},"comment":{"url":"https://api.github.com/repos/symfony/symfony/issues/comments/85068382","html_url":"https://github.com/symfony/symfony/issues/13988#issuecomment-85068382","issue_url":"https://api.github.com/repos/symfony/symfony/issues/13988","id":85068382,"user":{"login":"ircmaxell","id":660654,"avatar_url":"https://avatars.githubusercontent.com/u/660654?v=3","gravatar_id":"","url":"https://api.github.com/users/ircmaxell","html_url":"https://github.com/ircmaxell","followers_url":"https://api.github.com/users/ircmaxell/followers","following_url":"https://api.github.com/users/ircmaxell/following{/other_user}","gists_url":"https://api.github.com/users/ircmaxell/gists{/gist_id}","starred_url":"https://api.github.com/users/ircmaxell/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ircmaxell/subscriptions","organizations_url":"https://api.github.com/users/ircmaxell/orgs","repos_url":"https://api.github.com/users/ircmaxell/repos","events_url":"https://api.github.com/users/ircmaxell/events{/privacy}","received_events_url":"https://api.github.com/users/ircmaxell/received_events","type":"User","site_admin":false},"created_at":"2015-03-23T16:06:18Z","updated_at":"2015-03-23T16:06:18Z","body":"Question: why do you accept a salt on the command line in the first place? That seems like a problem to me. Instead, you should **always** generate it.\r\n\r\nIn fact, I'd raise the question of why encoders even accept a salt in the first place. They are a high-level abstraction, and as such should be generating salts automatically, not requiring one as input."}}