Re: URI para recursos de red
El día 12 de junio de 2013 15:13, Camaleón <noelamac@gmail.com> escribió:
> El Tue, 11 Jun 2013 23:14:59 +0200, fernando sainz escribió:
>
>> El día 11 de junio de 2013 19:25, Camaleón <noelamac@gmail.com>
>> escribió:
>>> Hola,
>>>
>>> ¿Es mi imaginación o ha dejado de funcionar el siguiente URI para
>>> acceder a recursos de red (samba, ftp...)?
>>>
>>> smb://usuario:contraseña@ip/recurso
>>> ftp://usuario:contraseña@ip
>>>
>>>
>> Bueno, aunque solo sea por seguridad me parece que eso era un
>> aberración.
>
> Yo no lo veo así.
No se por qué, pero no me sorprende ;-)
Pues en el mismo link que mandas dan un razonamiento al caso:
----
Use of the format "user:password" in the userinfo field is
deprecated. Applications should not render as clear text any data
after the first colon (":") character found within a userinfo
subcomponent unless the data after the colon is the empty string
(indicating no password). Applications may choose to ignore or
reject such data when it is received as part of a reference and
should reject the storage of such data in unencrypted form. The
passing of authentication information in clear text has proven to be
a security risk in almost every case where it has been used.
Applications that render a URI for the sake of user feedback, such as
in graphical hypertext browsing, should render userinfo in a way that
is distinguished from the rest of a URI, when feasible. Such
rendering will assist the user in cases where the userinfo has been
misleadingly crafted to look like a trusted domain name
(Section 7.6).
----
And section 7.5:
----
7.5. Sensitive Information
URI producers should not provide a URI that contains a username or
password that is intended to be secret. URIs are frequently
displayed by browsers, stored in clear text bookmarks, and logged by
user agent history and intermediary applications (proxies). A
password appearing within the userinfo component is deprecated and
should be considered an error (or simply ignored) except in those
rare cases where the 'password' parameter is intended to be public.
S2.
>
> Hay muchas configuraciones donde se requiere el combo de usuario/
> contraseña pero ambos valores son de uso público (p. ej., en un servidor
> ftp) o incluso en una red casera con un único ordenador y un NAS donde
> sólo hay un usuario.
>
> En cualquier caso, el usuario debe tener siempre la última palabra sobre
> la seguridad de sus sistemas, faltaría más ;-)
>
> Rebuscando por la web he visto el bug en GNOME. En fin, a ver si lo
> corrigen pronto porque lleva ya 3 añitos:
>
> FTP password not recognized
> https://bugzilla.gnome.org/show_bug.cgi?id=628430
>
> Saludos,
>
> --
> Camaleón
>
>
> --
> To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] pan.2013.06.12.13.13.41@gmail.com">http://lists.debian.org/[🔎] pan.2013.06.12.13.13.41@gmail.com
>
Reply to: